Confirm
716
edits
Changes
no edit summary
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].
'''Recommended solutions'''
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.
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 to fire an event in the handlers ServiceWorker and let the worker decide if a new page should be opened, or if an existing page could be used. But a reasonable default seems like always opening activity handlers in a new context. I.e. only allow reusing an existing context by registering a ServiceWorker as the handler.
=== Lack of ability to save intermediate results ===
Consider a "Google Drive" page that uses an "edit" activity to launch a "photoshop" page in order to edit a picture file. Once the user is done editing the picture the photoshop page could return the edited picture to the Google Drive page and Google Drive could save the edited picture using application specific logic.
=== Ability to switch from inline to full-page handler ===
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.
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 solution'''
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.
And activity handlers that don't return a value can always open new tabs using target=_blank links or window.open calls.
=== Should activity launcher have a say in disposition of the handler? ===
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''
For activities that does not return a value, the initiating page might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".
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 solution'''
Potentially we could support a ''target'' attribute when initiating an activity. 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?
