Serialization of JavaScript values does not appear to respect new HTML5 Structured Clone semantics

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Luke Zarko]

The layout tests at fast/dom/Window/window-postmessage-clone.html and fast/dom/Window/window-postmessage-clone-really-deep-array.html differ from the expected results in platform/chromium (both with the integration of the patch for https://bugs.webkit.org/show_bug.cgi?id=65286). Ideally the platform-specific expectations should be eliminated and the behavior of all platforms would be harmonized.

[David Levin]

This is about a fix that needs to happen the structured clone implementation in bindings/js.

[Luke Zarko]

The legacy behavior for postMessage differs between Chrome and Safari for https://bugs.webkit.org/show_bug.cgi?id=65209 -- where Chrome forbids MessagePorts from appearing within a message, Safari allows it but serializes them as plain Objects.

[Chris Dumez]

Created attachment 160008 [details]
Patch

[Oliver Hunt]

Comment on attachment 160008 [details]
Patch

Are the posted String/Boolean/Number objects expected to transfer expands? (a la Arrays)

Also this appears to result in breaking object identity semantics.  eg. foo=new String(s); bar = {a:foo, b:foo}; postMessage(bar)  will produce an object with data.a !== data.b despite bar.a === bar.b

If this is expected behaviour according to the spec i would consider it a spec bug.

[Build Bot]

Comment on attachment 160008 [details]
Patch

Attachment 160008 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/13574119

[Chris Dumez]

Created attachment 160014 [details]
Patch

Attempt to fix Windows build.

[Build Bot]

Comment on attachment 160014 [details]
Patch

Attachment 160014 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/13561423

[Chris Dumez]

Created attachment 160023 [details]
Patch

Another attempt to fix Windows build.

[Build Bot]

Comment on attachment 160023 [details]
Patch

Attachment 160023 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/13565465

[Build Bot]

Comment on attachment 160023 [details]
Patch

Attachment 160023 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/13563440

[Chris Dumez]

Created attachment 160100 [details]
Patch

Attempt to fix mac/win builds.

[Build Bot]

Comment on attachment 160100 [details]
Patch

Attachment 160100 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/13571541

[Chris Dumez]

Created attachment 160111 [details]
Patch

Export a few JSC symbols for Mac and Win.

[Build Bot]

Comment on attachment 160111 [details]
Patch

Attachment 160111 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/13559648

[Chris Dumez]

(In reply to comment #14)
> (From update of attachment 160111 [details])
> Attachment 160111 [details] did not pass mac-ews (mac):
> Output: http://queues.webkit.org/results/13559648

I added the symbols to Source/JavaScriptCore/JavaScriptCore.order. Any idea why I'm still getting linking errors on Mac?

[Mikhail Pozdnyakov]

(In reply to comment #15)
> (In reply to comment #14)
> > (From update of attachment 160111 [details] [details])
> > Attachment 160111 [details] [details] did not pass mac-ews (mac):
> > Output: http://queues.webkit.org/results/13559648
> I added the symbols to Source/JavaScriptCore/JavaScriptCore.order. Any idea why I'm still getting linking errors on Mac?

To export symbols from core you should add them to Source/WebCore/WebCore.exp.in

[Chris Dumez]

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > (From update of attachment 160111 [details] [details] [details])
> > > Attachment 160111 [details] [details] [details] did not pass mac-ews (mac):
> > > Output: http://queues.webkit.org/results/13559648
> > I added the symbols to Source/JavaScriptCore/JavaScriptCore.order. Any idea why I'm still getting linking errors on Mac?
> 
> To export symbols from core you should add them to Source/WebCore/WebCore.exp.in

AFAIK, WebCore.exp.in is used to export symbols from WebCore to WebKit API. In my case, I need to export symbols from JavaScriptCore to WebCore.

[Chris Dumez]

Created attachment 160120 [details]
Patch

Export several JSC symbols, hopefully fixing Mac build.

[Kentaro Hara]

This page might be helpful for you:
http://trac.webkit.org/wiki/ExportingSymbols

[Chris Dumez]

Created attachment 160121 [details]
Patch

Clean up the symbols export based on the wiki page Haraken provided (Thanks!)

[Chris Dumez]

Comment on attachment 160121 [details]
Patch

Will handle the object identify issue reported by Oliver.

[Chris Dumez]

Created attachment 160126 [details]
Patch

Fix the object identity issue mentionned by Oliver.

[WebKit Review Bot]

Comment on attachment 160126 [details]
Patch

Attachment 160126 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13563636

New failing tests:
animations/suspend-resume-animation-events.html

[WebKit Review Bot]

Created attachment 160128 [details]
Archive of layout-test-results from gce-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid

[Chris Dumez]

Comment on attachment 160126 [details]
Patch

Chrome warning seems unrelated. Setting cq? again.

[Chris Dumez]

Created attachment 160204 [details]
Patch

Bump CurrentVersion in SerializedScriptValue.cpp as requested on IRC.

[WebKit Review Bot]

Comment on attachment 160204 [details]
Patch

Clearing flags on attachment: 160204

Committed r126464: <http://trac.webkit.org/changeset/126464>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.