Can you clarify what action you expect of the bindings team here (or change to another component)? It's not clear to me what should be done here.

A couple of questions:
1. Why is the Transferable typedef in Window.idl, I was looking at the spec (https://html.spec.whatwg.org/#the-window-object) but I don't see the typedef defined there. Is there any current plan to standardize it?

2. PostMessage argument transfer, if the type should be sequence<Transferable>, we should update the spec too. I just checked WebKit and Gecko, their types match the spec, which is sequence<object>

> 1. Why is the Transferable typedef in Window.idl, I was looking at the spec (https://html.spec.whatwg.org/#the-window-object) but I don't see the typedef defined there. Is there any current plan to standardize it?

The Transferable typedef used to exist a few years ago. See http://web.archive.org/web/20140702223608/http://www.whatwg.org/specs/web-apps/current-work/#transferable-objects and  issue 393245 . At the time, we had

    typedef (ArrayBuffer or CanvasProxy or MessagePort) Transferable;

but the bindings layer did not support IDL unions. All existing uses in IDLs in Blink at the time (~2014) were of the form "MessagePort[] foo", which were then converted to "sequence<Transferable> foo" with Transferable being just a typedef to MessagePort.

> 2. PostMessage argument transfer, if the type should be sequence<Transferable>, we should update the spec too. I just checked WebKit and Gecko, their types match the spec, which is sequence<object>

This change comes from https://github.com/whatwg/html/commit/bfb960c938580c95e77365e614218b952f96375b. We need to update our IDL file. I think we also need to update the serialization code, but that's a lot more work. For one, SerializedScriptValue::ExtractTransferables() has a whitelist of types it accepts, whereas platform objects such as ImageBitmap should have the [Transferable] attribute in their interface declaration.

https://chromium-review.googlesource.com/c/561459/ addresses (1)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b

commit 5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Tue Jul 11 06:59:38 2017

Remove the Transferable typedef from Window.idl.

The typedef was added back in 2014 in commit 38b7b40abe5848dc ("Improve the
declared IDL type for postMessage()'s transferables"), when the HTML Living
Standard defined a Transferable typedef like this:

    typedef (ArrayBuffer or CanvasProxy or MessagePort) Transferable;

since the bindings layer did not support unions at the time and all uses of
Transferable in our IDLs amounted to MessagePort objects, the current
"typedef MessagePort Transferable" was introduced for compliance.

https://github.com/whatwg/html/commit/bfb960c938580c95e77365e614218b952f96375b ("Write
structured clone algorithm in terms of ECMAScript") got rid of the typedef
in the spec altogether though, so we were again not compliant in our IDLs.

This CL makes the switch by using object instead of Transferable in the
IDLs.

In practice, this does not make any difference, as |transfer| is always
parsed via SerializedScriptValue::ExtractTransferables(), which does all the
argument parsing on its own.

While here, also make a few other IDL updates that do not change the
generated bindings code, in some cases due to the fact that the
postMessage() bindings code is more customized than usual:
- Add a "= []" to the "optional sequence<object>" postMessage() arguments.
- Change |message|'s type from "SerializedScriptValue" to "any" in some
  postMessage() declarations to match the spec(s).
- Update the spec link in ServiceWorker.idl.

Bug: 701482
Change-Id: I0a5c0dc7fed8f3498ccd072b4422fb269e5def97
Reviewed-on: https://chromium-review.googlesource.com/561459
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#485542}
[modify] https://crrev.com/5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b/third_party/WebKit/Source/bindings/tests/idls/core/TestObject.idl
[modify] https://crrev.com/5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b/third_party/WebKit/Source/bindings/tests/results/core/V8TestObject.cpp
[modify] https://crrev.com/5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b/third_party/WebKit/Source/core/dom/MessagePort.idl
[modify] https://crrev.com/5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b/third_party/WebKit/Source/core/frame/Window.idl
[modify] https://crrev.com/5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b/third_party/WebKit/Source/core/workers/DedicatedWorkerGlobalScope.idl
[modify] https://crrev.com/5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b/third_party/WebKit/Source/core/workers/Worker.idl
[modify] https://crrev.com/5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b/third_party/WebKit/Source/modules/compositorworker/CompositorWorker.idl
[modify] https://crrev.com/5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b/third_party/WebKit/Source/modules/compositorworker/CompositorWorkerGlobalScope.idl
[modify] https://crrev.com/5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b/third_party/WebKit/Source/modules/serviceworkers/Client.idl
[modify] https://crrev.com/5a1e5f3ad0ce1651123ebb2515ebb2228b3f946b/third_party/WebKit/Source/modules/serviceworkers/ServiceWorker.idl

Does that resolve this issue?

The commit I landed only resolves the first issue raised in comment #4. The second one requires more work (especially to find out what "version" of the postMessage algorithm we actually implement and what changed in the specs since then) and I wasn't planning on looking into it for now.