Confirm
716
edits
Changes
no edit summary
'''Recommended solutions'''
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.
In a small-screen device this means that when the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.
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.
'''Recommended solutions'''
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.
For other activity handlers a good solution might be default is likely to always open a new tab to fire an event in handle the handlers activity. We could also allow using a ServiceWorker as activity handler, and let then allow the service worker to decide if a new page should be opened, or if an existing page could be used. But a reasonable default seems like always opening should handle the activity handlers in a new context. I.e. only Possibly we could even allow reusing an existing context by registering the ServiceWorker to open a ServiceWorker as the handlerdisposition:inline activity.
=== Lack of ability to save intermediate results ===
'''Recommended solutions'''
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.
This gets especially tricky for activity handlers that return a value. In this case the full-page handler would need to be rendered on top of the current page, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.
'''Recommended solutionsolutions'''
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive page, or if opening Photoshop should be treated like opening a <tt><a target="_blank"></tt> link.
'''Recommended solutionsolutions'''Potentially we We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which would involve targeting named windows.
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?
