Bug 66127

Created attachment 103747 [details] Patch

Comment on attachment 103747 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=103747&action=review SerializedScriptValue is used to support structured clones, so this change brings up a lot of questions at a high level: 1. Why is this change being done without adding blob to the general algorithm for structured clones? 2. Has the change to structured clones been talked about with the appropriate mailing lists (and what was the response)? 3. How does this fit with serializing to database and then pulling it back out in a later session? (For cross process, I get that the url should be global to the browser.) It would be useful to know if this has gone through a some public mailing list discussion. Thanks! > Source/WebCore/bindings/js/SerializedScriptValue.cpp:278 > + static bool serialize(PassRefPtr<Blob> blob, Vector<uint8_t>& out) Why does this take a PassRefPtr when it doesn't take ownership? (It doesn't put the passed in ref counted object into something like a RefPtr.) It looks like it should take a Blob*. > Source/WebCore/bindings/js/SerializedScriptValue.cpp:1387 > +PassRefPtr<SerializedScriptValue> SerializedScriptValue::create(PassRefPtr<Blob> blob) Ditto re PassRefPtr. > Source/WebCore/bindings/v8/SerializedScriptValue.cpp:1883 > +PassRefPtr<SerializedScriptValue> SerializedScriptValue::create(PassRefPtr<Blob> data) Ditto re PassRefPtr.

(In reply to comment #2) > (From update of attachment 103747 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=103747&action=review > > SerializedScriptValue is used to support structured clones, so this change brings up a lot of questions at a high level: > 1. Why is this change being done without adding blob to the general algorithm for structured clones? Cloning Blob was implemented in both JSC and V8 almost one year ago: - http://trac.webkit.org/changeset/57382 (Added Blob serialization in v8/SerializedScriptValue.cpp) - http://trac.webkit.org/changeset/65102 (Added SerializedBlob in js/SerializedScriptValue.cpp) My patch does NOT change or add any cloning algorithms; it just adds an internal interface to create a SerializedScriptObject representing a Blob (there is already a similar constructor for String), which will be necessary to construct a MessageEvent containing a Blob. > 2. Has the change to structured clones been talked about with the appropriate mailing lists (and what was the response)? Blob is already included in structured clone algorithm: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#safe-passing-of-structured-data If I understand correctly, copying a Blob is cheap; you only need to copy two small strings (url and type) and one integer (size). Backing binary data is owned and managed by the browser. > 3. How does this fit with serializing to database and then pulling it back out in a later session? (For cross process, I get that the url should be global to the browser.) I'm not sure -- folks from File API (cc'ed) may have insights on this. > > It would be useful to know if this has gone through a some public mailing list discussion. > > Thanks!

Created attachment 103892 [details] Patch v2

Comment on attachment 103747 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=103747&action=review >> Source/WebCore/bindings/js/SerializedScriptValue.cpp:278 >> + static bool serialize(PassRefPtr<Blob> blob, Vector<uint8_t>& out) > > Why does this take a PassRefPtr when it doesn't take ownership? (It doesn't put the passed in ref counted object into something like a RefPtr.) > > It looks like it should take a Blob*. Because serializing a null blob did not sound meaningful, "const Blob&" is used (instead of "Blob*") in patch v2. >> Source/WebCore/bindings/js/SerializedScriptValue.cpp:1387 >> +PassRefPtr<SerializedScriptValue> SerializedScriptValue::create(PassRefPtr<Blob> blob) > > Ditto re PassRefPtr. Fixed in patch v2 (see above). >> Source/WebCore/bindings/v8/SerializedScriptValue.cpp:1883 >> +PassRefPtr<SerializedScriptValue> SerializedScriptValue::create(PassRefPtr<Blob> data) > > Ditto re PassRefPtr. Fixed in patch v2 (see above).

Comment on attachment 103892 [details] Patch v2 View in context: https://bugs.webkit.org/attachment.cgi?id=103892&action=review Thanks! Just a few last comments. > Source/WebCore/bindings/js/SerializedScriptValue.cpp:279 > + static bool serialize(const Blob& blob, Vector<uint8_t>& out) Thanks for all of the information. This is why I thought blob was being added. Is there anyway to collapse this with the current serialization for blob rather than have two places where it is serialized and need to be maintained to do the same thing? (Because this seems like a place where things will easily go wrong in the future.) > Source/WebCore/bindings/v8/SerializedScriptValue.h:36 > +#include <wtf/Forward.h> Why is this being added?

Comment on attachment 103892 [details] Patch v2 View in context: https://bugs.webkit.org/attachment.cgi?id=103892&action=review >> Source/WebCore/bindings/js/SerializedScriptValue.cpp:279 >> + static bool serialize(const Blob& blob, Vector<uint8_t>& out) > > Thanks for all of the information. > > This is why I thought blob was being added. > > Is there anyway to collapse this with the current serialization for blob rather than have two places where it is serialized and need to be maintained to do the same thing? (Because this seems like a place where things will easily go wrong in the future.) You are right -- but it's hard to do it within the current design as long as CloneSerializer requires ExecState*. We probably should write something similar to "Writer" class which exists in v8/SerializedScriptObject.cpp. However, it requires a moderate amount of refactoring effort and does not seem to be a thing to be done in this change. I'll put a FIXME comment to this function. >> Source/WebCore/bindings/v8/SerializedScriptValue.h:36 >> +#include <wtf/Forward.h> > > Why is this being added? This was originally added for PassRefPtr<> (which has actually gone in patch v2), but I thought this was necessary because of String. It is not directly related to this patch, though.

(In reply to comment #7) > (From update of attachment 103892 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=103892&action=review > > >> Source/WebCore/bindings/js/SerializedScriptValue.cpp:279 > >> + static bool serialize(const Blob& blob, Vector<uint8_t>& out) > > > > Thanks for all of the information. > > > > This is why I thought blob was being added. > > > > Is there anyway to collapse this with the current serialization for blob rather than have two places where it is serialized and need to be maintained to do the same thing? (Because this seems like a place where things will easily go wrong in the future.) > > You are right -- but it's hard to do it within the current design as long as CloneSerializer requires ExecState*. > > We probably should write something similar to "Writer" class which exists in v8/SerializedScriptObject.cpp. However, it requires a moderate amount of refactoring effort and does not seem to be a thing to be done in this change. Feel free to do it before this change.

Comment on attachment 103892 [details] Patch v2 View in context: https://bugs.webkit.org/attachment.cgi?id=103892&action=review >>>> Source/WebCore/bindings/js/SerializedScriptValue.cpp:279 >>>> + static bool serialize(const Blob& blob, Vector<uint8_t>& out) >>> >>> Thanks for all of the information. >>> >>> This is why I thought blob was being added. >>> >>> Is there anyway to collapse this with the current serialization for blob rather than have two places where it is serialized and need to be maintained to do the same thing? (Because this seems like a place where things will easily go wrong in the future.) >> >> You are right -- but it's hard to do it within the current design as long as CloneSerializer requires ExecState*. >> >> We probably should write something similar to "Writer" class which exists in v8/SerializedScriptObject.cpp. However, it requires a moderate amount of refactoring effort and does not seem to be a thing to be done in this change. >> >> I'll put a FIXME comment to this function. > > Feel free to do it before this change. I'm happy to do this, but I think it's better to wait for a patch in bug 65209 to land because the change is likely to conflict severely.

(In reply to comment #9) > >> We probably should write something similar to "Writer" class which exists in v8/SerializedScriptObject.cpp. However, it requires a moderate amount of refactoring effort and does not seem to be a thing to be done in this change. > >> > >> I'll put a FIXME comment to this function. > > > > Feel free to do it before this change. > > I'm happy to do this, but I think it's better to wait for a patch in bug 65209 to land because the change is likely to conflict severely. We're trying hard to get that landed. Should have an update on that today.

Created attachment 104058 [details] Patch v3

(In reply to comment #11) > Created an attachment (id=104058) [details] > Patch v3 Added FIXME comments.

I don't think this should be landed in its current form as I tried to suggest in https://bugs.webkit.org/show_bug.cgi?id=66127#c8 If that needs to wait for https://bugs.webkit.org/show_bug.cgi?id=65209, then it should wait a little bit. That patch should land this week.

Sure.

Comment on attachment 104058 [details] Patch v3 View in context: https://bugs.webkit.org/attachment.cgi?id=104058&action=review > Source/WebCore/bindings/js/SerializedScriptValue.cpp:270 > + // FIXME: It's better to share the serialization code like Writer class in v8/SerializedScriptValue.cpp. I have no idea what this comment is saying. > Source/WebCore/bindings/js/SerializedScriptValue.cpp:280 > + static bool serialize(const Blob& blob, Vector<uint8_t>& out) Why do we need a specific entry point for Blob? > Source/WebCore/bindings/js/SerializedScriptValue.cpp:282 > + // FIXME: Ditto. Not a useful comment

This change has become unnecessary, because I was able to change MessageEvent so it could hold a variant value (see bug 66841). Abondoning this bug.