Add postMessage override that provides WindowPostMessageOptions. #3800

dtapuska · 2018-07-05T19:19:51Z

Fixes issue #3799

/web-messaging.html ( diff )
/window-object.html ( diff )
/workers.html ( diff )

dtapuska · 2018-07-05T19:20:42Z

Tentative WPT tests are here for review: https://chromium-review.googlesource.com/c/chromium/src/+/1118850

domenic

Some issues, but the basic idea is clear. I'll follow up with a more general comment in #3799.

I wonder whether we should update all of the spec examples to use this overload. If we believe it to be the right pattern in general, that might be a good idea. You can Ctrl+F for postMessage( in the rendered output to find a lot.

On the other hand, maybe spec examples should be a bit more conservative, not using newer, less-supported features.

domenic · 2018-07-10T20:45:57Z

source

+callback <dfn>FrameRequestCallback</dfn> = void (<span>DOMHighResTimeStamp</span> time);
+
+dictionary <dfn>WindowPostMessageOptions</dfn>
+{


Nit: curly on previous line

domenic · 2018-07-10T20:46:09Z

source

+{
+  USVString targetOrigin = "/";
+};
+</pre>


Nit: no \n before closing tag

domenic · 2018-07-10T20:48:22Z

source

@@ -95391,6 +95397,9 @@ function receiver(e) {
    <p>Objects listed in <var>transfer</var> are transferred, not just cloned, meaning that
    they are no longer usable on the sending side.</p>

+    <p>Target origin is specified as a member of <var>options</var>. If options is not provided
+    targetOrigin of the dictionary is initialized to "<code data-x="">/</code>".</p>


I would phrase this as:

A target origin may be specified using the <code data-x="">targetOrigin</code> member of <var>options</var>. If not provided, it defaults to "<code data-x="">/</code>". This restricts the message to same-origin targets only.

domenic · 2018-07-10T20:48:37Z

source

@@ -95391,6 +95397,9 @@ function receiver(e) {
    <p>Objects listed in <var>transfer</var> are transferred, not just cloned, meaning that
    they are no longer usable on the sending side.</p>

+    <p>Target origin is specified as a member of <var>options</var>. If options is not provided
+    targetOrigin of the dictionary is initialized to "<code data-x="">/</code>".</p>
+
    <p>If the origin of the target window doesn't match the given origin, the message is discarded,


We should change "given" to "target" here.

domenic · 2018-07-10T20:49:12Z

source

@@ -95391,6 +95397,9 @@ function receiver(e) {
    <p>Objects listed in <var>transfer</var> are transferred, not just cloned, meaning that
    they are no longer usable on the sending side.</p>

+    <p>Target origin is specified as a member of <var>options</var>. If options is not provided
+    targetOrigin of the dictionary is initialized to "<code data-x="">/</code>".</p>
+
    <p>If the origin of the target window doesn't match the given origin, the message is discarded,
    to avoid information leakage. To send the message to the target regardless of origin, set the
    target origin to "<code data-x="">*</code>". To restrict the message to same-origin targets only,


We can remove the "To restrict the message..." sentence now.

domenic · 2018-07-10T20:50:37Z

source

+
+    <p>This is an alternate version of postMessage where the target origin is specified as a parameter.
+    Calling <code data-x="">window.postMessage(message, target, transfer);</code> is equivalent
+    to <code data-x="">window.postMessage(message, transfer, {targetOrigin: target});</code>


Nits:

Wrapping not quite right. Use https://output.jsbin.com/maferi.

Missing </p>

Remove semicolons

Add period at the end

domenic · 2018-07-10T20:53:24Z

source

@@ -95417,7 +95435,7 @@ function receiver(e) {
  <div w-nodev>

  <p>The <dfn><code data-x="dom-window-postMessage">postMessage(<var>message</var>,


You lost the definition for postMessage(message, targetOrigin, transfer). It will need a second data-x, since it's a second method.

See https://html.spec.whatwg.org/#dom-document-open for the general pattern here. You'll need to define something like "window message-posting steps" which takes message, transfer, targetOrigin, then define the two methods each of which call the window message-posting steps.

domenic · 2018-07-10T20:54:23Z

source

@@ -95433,6 +95451,8 @@ function receiver(e) {
   window, in same-origin cases. See discussion at
   https://github.com/whatwg/html/issues/1542#issuecomment-233502636 -->

+   <li><p>Let <var>targetOrigin</var> be <var>options</var>'s targetOrigin.</p></li>


You can use either "the value of options's targetOrigin member" or (newer, rarer style) options["targetOrigin"].

dtapuska · 2018-07-24T16:27:37Z

Ok; transfer moved to the dictionary. It digresses from the consistency we were after but I think the argument to put it in the dictionary is reasonable.

wanderview · 2018-07-31T15:37:35Z

If we're updating all versions of postMessage(), then please also update ServiceWorker.postMessage() and Client.postMessage() in the service worker spec.

https://w3c.github.io/ServiceWorker/#service-worker-postmessage
https://w3c.github.io/ServiceWorker/#client-postmessage

dtapuska · 2018-07-31T15:41:48Z

Yes that is the intent. We have to agree on it first though.. See #3799 where the main discussion is happening.

domenic

Lots of editorial work to do, but normative aspects all look good, thanks!

domenic · 2018-08-01T16:52:39Z

source

+    <var>options</var>. If not provided, it defaults to "<code data-x="">/</code>". This restricts
+    the message to same-origin targets only.</p>
+
+    <p>This is an alternate version of postMessage where the target origin is specified as a


Stray paragraph; delete

domenic · 2018-08-01T16:53:45Z

source

@@ -95356,29 +95361,41 @@ function receiver(e) {

  <dl class="domintro">

-   <dt><var>window</var> . <code subdfn data-x="dom-window-postMessage">postMessage</code>(<var>message</var>, <var>targetOrigin</var> [, <var>transfer</var> ] )</dt>
+   <dt><var>window</var> . <code subdfn data-x="dom-window-postMessage">postMessage</code>(<var>message</var>[, <var>options</var> ])</dt>


Nit: space between ] and ), I guess? Spec is inconsistent, but we should be consistent within this block, at least. I'm also OK with deleting the space from the below.

domenic · 2018-08-01T16:54:31Z

source

+
+   <dd>
+
+    <p>This is an alternate version of postMessage where the target origin is specified as a


postMessage -> <code data-x="dom-window-postMessage-options">postMessage()</code>

domenic · 2018-08-01T16:54:57Z

source

+    <p>This is an alternate version of postMessage where the target origin is specified as a
+    parameter. Calling <code data-x="">window.postMessage(message, target, transfer)</code> is
+    equivalent to <code data-x="">window.postMessage(message, transfer, {targetOrigin:
+    target})</code>.</p>


This needs updating since transfer moved into the options dictionary.

domenic · 2018-08-01T16:55:14Z

source

-  <p>The <dfn><code data-x="dom-window-postMessage">postMessage(<var>message</var>,
-  <var>targetOrigin</var>, <var>transfer</var>)</code></dfn> method, when invoked on a
-  <code>Window</code> object must run the following steps:</p>
+  <p>The <dfn>window post message steps</dfn>, given a <var>targetWindow</var>, <var>message</var>


Comma after message and after options

domenic · 2018-08-01T19:26:53Z

source

+   <li><p>Let <var>targetPort</var> be the port with which this <code>MessagePort</code> is
+   entangled, if any; otherwise let it be null.</p></li>
+
+   <li><p>Let <var>options</var> be a new instance of <code>PostMessageOptions</code>


Same simplification as above.

domenic · 2018-08-01T19:27:54Z

source

@@ -96914,6 +97012,13 @@ interface <dfn>DedicatedWorkerGlobalScope</dfn> : <span>WorkerGlobalScope</span>
   <var>dedicatedWorkerGlobal</var>. <var>transfer</var> can be passed as a list of objects that are
   to be transferred rather than cloned.</dd>

+   <dt><var>dedicatedWorkerGlobal</var> . <code subdfn


Same dt/dt/dd structure as before.

domenic · 2018-08-01T19:28:43Z

source

+  and <dfn><code data-x="dom-DedicatedWorkerGlobalScope-postMessage-options">postMessage()</code></dfn>
+  methods on <code>DedicatedWorkerGlobalScope</code> objects act as if, when invoked, it
+  immediately invoked the respective <span data-x="dom-MessagePort-postMessage">postMessage</span>
+  and  <span data-x="dom-MessagePort-postMessage-options">postMessage (with options)</span> on the port,


Use code, not span.

Insert parameter lists for all four methods.

domenic · 2018-08-01T19:29:19Z

source

@@ -97653,6 +97761,12 @@ enum <dfn>WorkerType</dfn> { "classic", "module" };
   <dd>Clones <var>message</var> and transmits it to <var>worker</var>'s global environment.
   <var>transfer</var> can be passed as a list of objects that are to be transferred rather than
   cloned.</dd>
+
+   <dt><var>worker</var> . <code subdfn data-x="dom-Worker-postMessage-options">postMessage</code>(<var>message</var> [, <var>options</var> ])


Same dt/dt/dd structure as before.

domenic · 2018-08-01T19:29:38Z

source

@@ -97668,10 +97782,12 @@ enum <dfn>WorkerType</dfn> { "classic", "module" };
  <p>All messages received by that port must immediately be retargeted at the <code>Worker</code>
  object.</p>

-  <p>The <dfn><code data-x="dom-Worker-postMessage">postMessage()</code></dfn> method on


Use span, not code; add parameter lists to all four.

This is similar to the HTML changes in whatwg/html#3800

foolip · 2018-08-17T10:43:24Z

Even though it shows up in the thread, I had a hard time spotting the corresponding changes for Service Workers. Here they are: w3c/ServiceWorker#1344

annevk · 2018-09-28T14:23:03Z

source

+callback <dfn>FrameRequestCallback</dfn> = void (<span>DOMHighResTimeStamp</span> time);
+
+dictionary <dfn>WindowPostMessageOptions</dfn> : <span>PostMessageOptions</span> {
+  USVString targetOrigin = "/";


Should we name this simply "origin" for convenience?

Hmm, I think the explicitness is good. This isn't "the origin of a posted message", as origin would indicate, it's "the target origin to which you are posting the message".

Mkay, I don't like that it gets so long.

annevk · 2018-09-28T14:24:02Z

source

+   "<var>transfer</var>" → <var>transfer</var> ]».</p></li>
+
+   <li><p>Run the <span>window post message steps</span> providing
+   <var>targetWindow</var>, <var>message</var> and <var>options</var>.</p></li>


Oxford comma.

annevk · 2018-09-28T14:24:08Z

source

+   <li><p>Let <var>targetWindow</var> be this <code>Window</code> object.</p></li>
+
+   <li><p>Run the <span>window post message steps</span> providing <var>targetWindow</var>,
+   <var>message</var> and <var>options</var>.</p></li>


Oxford comma.

domenic · 2018-09-28T15:35:19Z

Removing "needs implementer interest" per #3799 (comment). Also please rebase on master, I guess there have been conflicts.

dtapuska · 2018-10-02T20:39:47Z

Commas addressed PTAL.

annevk

I wonder if for the non-Window postMessage() methods we should mark the transfer argument as non-optional and non-defaulting. It probably doesn't matter, but it seems slightly cleaner to make overloading pick the dictionary-based version as much as possible.

I also pushed some formatting nits.

Are the tests updated as well? The link in the comment following OP is rather outdated.

Fixes issue whatwg#3799

domenic · 2018-10-26T14:33:27Z

Tests ended up in https://github.com/web-platform-tests/wpt/tree/5a792b6bf4e0d39f2b65301b592dffffa8bd9b15/webmessaging/with-options. I'll merge this, and file an issue to make them un-.tentative.

domenic · 2018-10-26T14:47:05Z

@dtapuska did you, or can you, file issues on the other implementers?

dtapuska · 2018-10-29T13:47:48Z

Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1502802
Webkit: https://bugs.webkit.org/show_bug.cgi?id=191028
Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/19444772/

This is similar to the HTML changes in whatwg/html#3800

domenic requested changes Jul 10, 2018

View reviewed changes

domenic added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Jul 10, 2018

dtapuska force-pushed the post_message branch 2 times, most recently from a2fdfb3 to c9bf3a9 Compare July 24, 2018 16:25

dtapuska force-pushed the post_message branch from c9bf3a9 to 4df7974 Compare July 30, 2018 15:21

dtapuska force-pushed the post_message branch from 82fe6ec to b83e3ee Compare July 31, 2018 20:47

domenic reviewed Aug 1, 2018

View reviewed changes

dtapuska force-pushed the post_message branch from b83e3ee to ba6e239 Compare August 10, 2018 16:33

dtapuska added a commit to dtapuska/ServiceWorker that referenced this pull request Aug 10, 2018

Add API for postMessage with PostMessageOptions

a7e8b79

This is similar to the HTML changes in whatwg/html#3800

dtapuska mentioned this pull request Aug 10, 2018

Add API for postMessage with PostMessageOptions w3c/ServiceWorker#1344

Closed

dtapuska mentioned this pull request Aug 21, 2018

User Activation API w3ctag/design-reviews#300

Closed

5 tasks

dtapuska mentioned this pull request Sep 6, 2018

User activation API #4009

Closed

sideshowbarker added normative change impacts documentation Used by documentation communities, such as MDN, to track changes that impact documentation labels Sep 11, 2018

annevk reviewed Sep 28, 2018

View reviewed changes

domenic removed the needs implementer interest Moving the issue forward requires implementers to express interest label Sep 28, 2018

dtapuska force-pushed the post_message branch from ba6e239 to 089985e Compare October 2, 2018 20:37

annevk approved these changes Oct 5, 2018

View reviewed changes

dtapuska and others added 3 commits October 26, 2018 16:18

Add postMessage overloads that provide PostMessageOptions.

473195e

Fixes issue whatwg#3799

formatting

858a2ec

Formatting and domintro fixups

2f1f275

domenic force-pushed the post_message branch from 4f60284 to 2f1f275 Compare October 26, 2018 14:26

Restore deleted domintro paragraph

cf7b9b9

domenic approved these changes Oct 26, 2018

View reviewed changes

domenic merged commit c501dd8 into whatwg:master Oct 26, 2018

domenic mentioned this pull request Oct 26, 2018

Un-.tentative the with-options postMessage() tests web-platform-tests/wpt#13736

Closed

KiChjang mentioned this pull request Oct 26, 2018

Use WindowPostMessageOptions on {Window, Worker}.postMessage servo/servo#22027

Open

annevk mentioned this pull request Oct 29, 2018

" void postMessage(any message, optional sequenc..." #4137

Closed

dtapuska added a commit to dtapuska/ServiceWorker that referenced this pull request Oct 29, 2018

Add API for postMessage with PostMessageOptions

060b6c3

This is similar to the HTML changes in whatwg/html#3800

dtapuska deleted the post_message branch October 29, 2018 15:58

dtapuska added a commit to dtapuska/ServiceWorker that referenced this pull request Mar 7, 2019

Add API for postMessage with PostMessageOptions

999e1bd

This is similar to the HTML changes in whatwg/html#3800

mfalken pushed a commit to w3c/ServiceWorker that referenced this pull request Mar 8, 2019

Add API for postMessage with PostMessageOptions

3b31974

This is similar to the HTML changes in whatwg/html#3800

		@@ -95417,7 +95435,7 @@ function receiver(e) {
		<div w-nodev>

		<p>The <dfn><code data-x="dom-window-postMessage">postMessage(<var>message</var>,


		<dd>

		<p>This is an alternate version of postMessage where the target origin is specified as a

Add postMessage override that provides WindowPostMessageOptions. #3800

Add postMessage override that provides WindowPostMessageOptions. #3800

Conversation

dtapuska commented Jul 5, 2018 • edited by pr-preview bot Loading

dtapuska commented Jul 5, 2018 • edited Loading

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dtapuska commented Jul 24, 2018

wanderview commented Jul 31, 2018 • edited Loading

dtapuska commented Jul 31, 2018

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

foolip commented Aug 17, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic commented Sep 28, 2018

dtapuska commented Oct 2, 2018

annevk left a comment

Choose a reason for hiding this comment

domenic commented Oct 26, 2018

domenic commented Oct 26, 2018

dtapuska commented Oct 29, 2018

dtapuska commented Jul 5, 2018 •

edited by pr-preview bot

Loading

dtapuska commented Jul 5, 2018 •

edited

Loading

wanderview commented Jul 31, 2018 •

edited

Loading