Changes

Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.

# User writes short message to go along with the URL and submits the tweet

In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.

On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.

In FirefoxOS a webactivity always launches a new fullpage app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.

This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.

In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.

We could also allow using a ServiceWorker as activity handler, and then allow the service worker to decide if a new page or an existing page should handle the activity. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.

Consider a "Google Drive" page that uses an "edit" activity to launch a "photoshop" page in order to edit a picture file.

The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.

A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.

And activity handlers that don't return a value can always open new tabs using target=_blank links or window.open calls.

''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''