postMessageAndAwaitResponse() to stable in 39

[David Michael]

Hi,

I think postMessageAndAwaitResponse() is (almost*) ready to go to stable.

I had planned on 40 because that's when NPAPI deprecation happens, but plugin authors are very interested in getting it sooner. Part of the problem is that Chrome Mac is moving from 32-bit to 64-bit in 39, which will make a lot of plugins stop working (even though NPAPI is strictly speaking still supported).

Here's the CL:

https://codereview.chromium.org/600893002/

Here's the bug:

https://code.google.com/p/chromium/issues/detail?id=367896

Here's the proposal doc:

https://docs.google.com/a/chromium.org/document/d/15XR5glTu15Pp7AbB5a8Kvvr0U6ycF3n-CvBkk9zU-t0/edit

Here's the PSA from chromium-dev/blink-dev:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/Mtx5qPU9V3Q/OW0S3MWGeJwJ

It's been in Canary & Dev since M37. Issues recently resolved:

1) Works in PNaCl

2) Has a C++ wrapper

3) Can't re-enter JavaScript (this was a pre-existing issue, actually)

4) Blocking callbacks are disallowed while in HandleBlockingMessage

Thanks!

-Dave

* (I intend to fix crbug.com/417316 by branch, and I owe the SDK an example)

[Molly Mackinlay]

+1!!!

typed with care on tiny keys

To unsubscribe from this group and stop receiving emails from it, send an email to pepper-dev+...@chromium.org.

[David Michael]

The one remaining wart with the API has proven too hard to fix in time for 39. So our options look like this:

1) Ship to stable in 40 (that will be plenty of time to fix the problem)

or

2) Ship to stable in 39, with a caveat:

FileRef and FileSystem resources have browser-side hosts, so postMessage has to round-trip with the browser for these, and delay sending the message.

So: If the plugin attempts to send a FileRef or FileSystem resource via postMessageAndAwaitResponse, it will fail with an exception.

Worse...  if the plugin sends a FileRef or FileSystem exception via postMessage, then later tries to use postMessageAndAwaitResponse, it *might* fail. I.e., it will fail if the round-trip with the browser hasn't finished. In this case, it fails loudly with an exception.

(See crbug.com/417316 and the work-in-progress fix https://codereview.chromium.org/605593002/)

I would just wait until 40 as I'd originally planned except plugin authors are concerned about the Mac user base they'll lose when Mac 39 goes 64-bit. Given that NPAPI didn't have file-passing, I expect none of these plugins being ported will notice. I think developers would probably rather have this wart and be able to use the API in 39.

So my inclination is to go ahead with it. But I wanted to give the chance for people to object or veto.

Thanks!

-Dave

[Darin Fisher]

Seems like a reasonable decision given that no one is using this API yet. We should just document this issue.

By the way, if two web pages are rendered by the same renderer process, and one does postMessage passing a FileRef and the other uses postMessageAndAwaitResponse, can we end up triggering the exception as you describe above?

-Darin

[David Michael]

On Fri, Sep 26, 2014 at 1:16 PM, Darin Fisher <da...@chromium.org> wrote:

Seems like a reasonable decision given that no one is using this API yet. We should just document this issue.

Good point; I haven't added this bit to the headers yet. I'll do that.

 

By the way, if two web pages are rendered by the same renderer process, and one does postMessage passing a FileRef and the other uses postMessageAndAwaitResponse, can we end up triggering the exception as you describe above?

Great question. It's a per-plugin-instance problem, so renderers won't affect each other this way.

(Details: There's nothing stopping me from actually sending the sync message under the hood, except that in this case I would cause messages to arrive out-of-order. I.e., the sync message would jump ahead of the async message(s) containing FileRef and/or FileSystem. So I throw an exception instead, to avoid that happening).

[Erik Kay]

Thanks David.  I agree with Darin.  This seems reasonable to ship with the caveat.  If I'm understanding it correctly, it would be safe to fix in a backwards compatible way, right?

Erik

[David Michael]

That's right, should be directly backwards compatible. What's in 39 is a strict subset of what will be in 40.