Current spec for window.postMessage states the following argument list for postMessage: postMessage(msg, targetOrigin [, transferables]) However, legacy implementation in WebKit used a different order: postMessage(msg [, transferables], targetOrigin). Changing this in https://bugs.webkit.org/show_bug.cgi?id=73589 was a backwards-incompatible change.
Link to the current (editor's draft) spec: http://dev.w3.org/html5/postmsg/#posting-messages
Created attachment 118292 [details] Fix This fix accepts legacy argument order (postMessage(msg, transferables, targetOrigin)) when third argument is a string. This is not 100% backward-compatible (previous version was also working for objects whose toString returned a valid target origin), but I think it is close enough so as not to break the Internet.
Comment on attachment 118292 [details] Fix View in context: https://bugs.webkit.org/attachment.cgi?id=118292&action=review Why are we doing this for V8 bindings only? > Source/WebCore/bindings/v8/custom/V8DOMWindowCustom.cpp:318 > + if (isLegacyTargetOriginDesignation(args[2])) { It might be worth issuing a deprecation warning message to the console when the compatibility logic kicks in.
(In reply to comment #3) > (From update of attachment 118292 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=118292&action=review > > Why are we doing this for V8 bindings only? JSC patch will follow (https://bugs.webkit.org/show_bug.cgi?id=73691). > > > Source/WebCore/bindings/v8/custom/V8DOMWindowCustom.cpp:318 > > + if (isLegacyTargetOriginDesignation(args[2])) { > > It might be worth issuing a deprecation warning message to the console when the compatibility logic kicks in. How to do that? Any examples? Will issuing message to the console cause perf regression?
> > Why are we doing this for V8 bindings only? > > JSC patch will follow (https://bugs.webkit.org/show_bug.cgi?id=73691). I think it logically belongs to a single patch, along with DOMWindow.idl change. > > It might be worth issuing a deprecation warning message to the console when the compatibility logic kicks in. > > How to do that? Any examples? Check out this: http://www.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/dom/UIEvent.cpp&exact_package=chromium&l=108 Or this: http://www.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/webaudio/AudioContext.cpp&exact_package=chromium&ct=rc&cd=4&l=392 > Will issuing message to the console cause perf regression? Not sure if this is critical, but if it is, we could limit the number of time we issue the message.
(In reply to comment #5) > > > Why are we doing this for V8 bindings only? > > > > JSC patch will follow (https://bugs.webkit.org/show_bug.cgi?id=73691). > > I think it logically belongs to a single patch, along with DOMWindow.idl change. > > > > It might be worth issuing a deprecation warning message to the console when the compatibility logic kicks in. > > > > How to do that? Any examples? > > Check out this: > > http://www.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/dom/UIEvent.cpp&exact_package=chromium&l=108 Thank you - looks really simple. Will add.
(In reply to comment #6) > (In reply to comment #5) > > > > Why are we doing this for V8 bindings only? > > > > > > JSC patch will follow (https://bugs.webkit.org/show_bug.cgi?id=73691). > > > > I think it logically belongs to a single patch, along with DOMWindow.idl change. > > > > > > It might be worth issuing a deprecation warning message to the console when the compatibility logic kicks in. > > > > > > How to do that? Any examples? > > > > Check out this: > > > > http://www.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/dom/UIEvent.cpp&exact_package=chromium&l=108 > > Thank you - looks really simple. Will add. On second thoughts, this will cause deprecation warnings in (shipping) chrome extensions, so coordinated changes in them will be required. In the interest of making this patch as small as possible, this will be done in a separate patch: https://bugs.webkit.org/show_bug.cgi?id=74045
(In reply to comment #6) > (In reply to comment #5) > > > > Why are we doing this for V8 bindings only? > > > > > > JSC patch will follow (https://bugs.webkit.org/show_bug.cgi?id=73691). > > > > I think it logically belongs to a single patch, along with DOMWindow.idl change. > > I do not think this is necessary. JSC bindings as in the tree today implement legacy behavior, following DOMWindow.idl. Let us keep patches small.
Comment on attachment 118292 [details] Fix Clearing flags on attachment: 118292 Committed r102317: <http://trac.webkit.org/changeset/102317>
All reviewed patches have been landed. Closing bug.