WebAPI for message confirmation

[Luke Wagner]

I have a specific use case which Jonas thought motivated a general solution to a related set of problems:

There are plans and a patch (in bug 839058) for an 'install-complete' message delivered to interested apps right after installation. Unfortunately, the handling of this message does not block the FFOS install UI which means that the app can be launched before it has finished handling 'install-complete'. This makes 'install-complete' unsuitable for constructor-like operations which establish some initial state for the app. What I'd like is if there was a way for an app to respond that the message was handled so that the FFOS install UI could wait for this message before declaring the app "installed" and allowing the user to run the app.

>From Jonas's reply:

In general we need a mechanism for system message handlers to indicate
that they have successfully handled a message. This is something that
has been discussed before and is needed for other reasons (dataloss in
case of crash for example). If we had that we could wait with
considering the application successfully installed until the message
was handled.

So perhaps then the proposal is for some standard for indicating messages as being "handled". One thought is that, by default, a message would be considered handled once the handler function returns (so, what we have now), but a handler function could indicate "This message should not be considered handled until I send you a message" (rather like SimpleTest.waitForExplicitFinish() in mochitests).

Cheers,
Luke

[Ehsan Akhgari]

I guess one way to do this would be to expose the following two new
functions on nsIDOMNavigatorSystemMessages:

void mozSetMessagePending(in DOMString type);
void mozMessageHandled(in DOMString type);

The handler for a given message can use these methods as follows:

function handler(message) {
spawnAsyncWork(message);
navigator.mozSetMessagePending("install-complete");
}

function spawnAsyncWork(message) {
(new Work()).then(function() {
navigator.mozMessageHandled("install-complete");
});
}

One detail is the notion of "pending" messages in the current API. In
order to avoid name clashes with those messages, we can perhaps choose a
better name here. (Suggestions?)

Does this sound like what you had in mind?

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>

[Luke Wagner]

Yes indeed, thanks!

I wonder if we also need an analogous API for sending a message and receiving a callback when the message is handled. Without any actual knowledge of how app installation is implemented in FFOS, I'd guess this is what the install UI would use to send the "install-complete" message and the callback would allow the installation to complete. I'd be interested to hear from someone more familiar with installation, though.

[janjo...@gmail.com]

On Saturday, November 30, 2013 2:15:00 AM UTC+1, Luke Wagner wrote:
> I wonder if we also need an analogous API for sending a message and receiving a callback when the message is handled. Without any actual knowledge of how app installation is implemented in FFOS, I'd guess this is what the install UI would use to send the "install-complete" message and the callback would allow the installation to complete. I'd be interested to hear from someone more familiar with installation, though.

I would really like something like that, I've ran into the use case of sending a message from XPCom to system app and I needed information back (this is what we do in keyboard_manager f.e. where the list of keyboards lives in gaia). You have to write your own 'callback-like' structure every time now.

[Jonas Sicking]

On Nov 21, 2013 12:06 PM, "Luke Wagner" <lu...@mozilla.com> wrote:
>
> I have a specific use case which Jonas thought motivated a general solution to a related set of problems:
>
> There are plans and a patch (in bug 839058) for an 'install-complete' message delivered to interested apps right after installation. Unfortunately, the handling of this message does not block the FFOS install UI which means that the app can be launched before it has finished handling 'install-complete'.

We should do two things here.

1. Improve system messages
We should add a way for applications to indicate that they have
handled a system message. Ehsan provided one such syntax. I would
prefer to reuse the syntax that Service Workers use:

setMessageHandler("install-complete", myHandler);
function myHandler(messageData, message) {
// messageData is what we're already sending with all system messages.
// It's contents depends on the specific system message
promise = doAsyncWork(messageData);
message.waitUntil(promise);
}

The new part here is the second argument to the message handler. This
object just has a single function, waitUntil. If called before the
message handler returns, it signals that the page needs to do more
work before it has fully handled the message.

To signal that you've handled the message, resolve the passed in promise.

This also enables the app to signal that it was unable to process the
message. To do this reject the promise passed to waitUntil.

This also means that we need to extend our internal APIs that we use
to send system messages. That API should return a promise. The promise
is rejected if the app crashes before it has time to finish running
the system message handler, or if the promise passed to waitUntil is
rejected.

The promise is resolved if the handler successfully returns from the
system message handler without calling waitUntil and without crashing.
The promise is also resolved if the promise passed to waitUntil is
successfully resolved.

2. Make install-complete delay the app being installed.
We should not consider an app fully installed until the
install-complete message handler has been fully run.

This is a little bit tricky since all parts of our platform needs to
consider the app fully installed so that it can run normally. However
the WebApp API should still indicate that the app isn't installed so
that the homescreen doesn't show it as installed, and so that the
marketplace doesn't show it as installed.

/ Jonas

[Ehsan Akhgari]

This indeed sounds better than my proposal!

> 2. Make install-complete delay the app being installed.
> We should not consider an app fully installed until the
> install-complete message handler has been fully run.
>
> This is a little bit tricky since all parts of our platform needs to
> consider the app fully installed so that it can run normally. However
> the WebApp API should still indicate that the app isn't installed so
> that the homescreen doesn't show it as installed, and so that the
> marketplace doesn't show it as installed.

CCing Fabrice who might have ideas on how to accomplish this...

Cheers,
Ehsan

[Ehsan Akhgari]

FWIW we discussed this today again and ended up with a simpler alternative,
please see bug 965970.

--
Ehsan
<http://ehsanakhgari.org/>