Make ImageBitmap transfers work in cases that require serialization

Make ImageBitmap transfers work in cases that require serialization

Transferring an ImageBitmap object, until now, relied on sharing a
RefPtr with the destination realm in order to pass the pixel data.
This mechanism does not work for all post message use cases. Some
cases require full serialization.  This change fixes the all the
postMessage interfaces that use the PostMessage extended attribute
in the IDL by employing the same strategy that was used for
ArrayBuffer: to fallback to the structured clone code path, and neuter
the source object.  This change does not fix window.postMessage

BUG=667910
Committed: https://crrev.com/6df1a49e882a63a088bbb2f62fe5a3b30c6d0633
Cr-Commit-Position: refs/heads/master@{#436774}

[Justin Novosad, 2016-11-29 22:47:22]

junov@chromium.org changed reviewers:
+ haraken@chromium.org

[Justin Novosad, 2016-11-29 22:47:22]

PTAL

[Justin Novosad, 2016-11-29 23:09:34]

The CQ bit was checked by junov@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-29 23:10:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-30 01:13:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-30 01:13:52]

Dry run: Try jobs failed on following builders:
  blimp_linux_dbg on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  chromeos_x86-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_clobber_rel_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)

[Justin Novosad, 2016-12-05 16:18:20]

haraken: friendly ping.

[haraken, 2016-12-06 00:22:10]

LGTM

I'm just curious but do you know why canTransferArrayBuffersAndImageBitmaps
returns true only in dedicated workers and compositor workers?

On 2016/12/05 16:18:20, Justin Novosad wrote:
> haraken: friendly ping.

Sorry, I missed this. Feel free to ping me if I didn't respond in 24 hours.

[nhiroki, 2016-12-06 02:06:13]

On 2016/12/06 00:22:10, haraken wrote:
> I'm just curious but do you know why canTransferArrayBuffersAndImageBitmaps
> returns true only in dedicated workers and compositor workers?

Because transfer requires that both sender context and destination context are
in the same process (because of current implementation limit), and that's always
guaranteed on dedicated workers and compositor workers. ServiceWorker,
ServiceWorkerClient, and MessagePort can be in a different process.

[haraken, 2016-12-06 02:09:49]

On 2016/12/06 02:06:13, nhiroki wrote:
> On 2016/12/06 00:22:10, haraken wrote:
> > I'm just curious but do you know why canTransferArrayBuffersAndImageBitmaps
> > returns true only in dedicated workers and compositor workers?
> 
> Because transfer requires that both sender context and destination context are
> in the same process (because of current implementation limit), and that's
always
> guaranteed on dedicated workers and compositor workers. ServiceWorker,
> ServiceWorkerClient, and MessagePort can be in a different process.

Ah, thanks, makes sense.

[Justin Novosad, 2016-12-06 21:09:48]

The CQ bit was checked by junov@chromium.org

[commit-bot: I haz the power, 2016-12-06 21:10:49]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-07 00:26:43]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1481058588757620, "parent_rev":
"b51fcbb98a81060e7a3f991887d5b7111b12c9c7", "commit_rev":
"3138cf583ff3c3911bc796bfadb000f779e5c119"}

[commit-bot: I haz the power, 2016-12-07 00:27:13]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-12-07 00:29:10]

Description was changed from

==========
Make ImageBitmap transfers work in cases that require serialization

Transferring an ImageBitmap object, until now, relied on sharing a
RefPtr with the destination realm in order to pass the pixel data.
This mechanism does not work for all post message use cases. Some
cases require full serialization.  This change fixes the all the
postMessage interfaces that use the PostMessage extended attribute
in the IDL by employing the same strategy that was used for
ArrayBuffer: to fallback to the structured clone code path, and neuter
the source object.  This change does not fix window.postMessage

BUG=667910
==========

to

==========
Make ImageBitmap transfers work in cases that require serialization

Transferring an ImageBitmap object, until now, relied on sharing a
RefPtr with the destination realm in order to pass the pixel data.
This mechanism does not work for all post message use cases. Some
cases require full serialization.  This change fixes the all the
postMessage interfaces that use the PostMessage extended attribute
in the IDL by employing the same strategy that was used for
ArrayBuffer: to fallback to the structured clone code path, and neuter
the source object.  This change does not fix window.postMessage

BUG=667910

Committed: https://crrev.com/6df1a49e882a63a088bbb2f62fe5a3b30c6d0633
Cr-Commit-Position: refs/heads/master@{#436774}
==========

[commit-bot: I haz the power, 2016-12-07 00:29:12]

Patchset 1 (id:??) landed as
https://crrev.com/6df1a49e882a63a088bbb2f62fe5a3b30c6d0633
Cr-Commit-Position: refs/heads/master@{#436774}