Local Presentation API to enable child-window presentation documents

[markafoltz]

Currently the Presentation API can only present fully fledged documents which are loaded in a separate (and isolated) browsing context. There may be use cases where it is not possible or desirable to render the intended content in a separate UA or a separate context.

1. The controlling UA has access to resources that can't easily be accessed elsewhere (because of login, VPN, etc.)
2. The controlling UA has some hardware capabilties (like a powerful GPU) required to render the content
3. The controlling UA has a known set of fonts or other assets that might not be available elsewhere
4. Messaging between the controller and presentation is too slow or awkward for the application (also thinking of gaming)

There may be other use cases as well.

In my thinking there could be two avenues to explore:

• A spec change to require 1-UA mode for rendering the presentation (helps with 1, 2, 3)
• A new API to present an offscreen frame or canvas that is part of the controlling document in 1-UA mode (helps with all of the above)

[tidoust]

For reference, see related discussion at TPAC

[markafoltz]

Updates

There is a third requirement which is related to the above. We've found that some controlling pages have authentication state in its cookie jar that can't be shared with the presentation (for security reasons, or because it owned by other origins). This makes it difficult for the presentation to obtain the necessary resources.

• The first approach (forced 1-UA) could also allow sharing of part of the cookie jar and other local storage for certain origins.
• The second approach (offscreen frame) would also address this requirement since the presentation is part of the same document.

In either scenario, reconnection to the presentation doesn't make sense or seems problematic from a security point of view.

Note that Media Capture from Element, along with WebRTC, allows a limited form of the second approach.

I'll be able to share some feedback on this from developers and possibly concrete proposals at TPAC.

[markafoltz]

This is an important item from our perspective, as it addresses specific challenges we have had with adoption of the Presentation API.

[markafoltz]

Wrote up a brief explainer for F2F discussion.

https://mfoltzgoogle.github.io/remote-window-api/explainer.md

[markafoltz]

From https://www.w3.org/2017/11/06-webscreens-minutes.html#x18:

ACTION: @mfoltzgoogle to refine the Remote Window API proposal and see if people prefer this over current 1-UA mode, evaluate similar Android API

ACTION: @anssiko to add this v2 feature provisionally to the Charter 2018

[anssiko]

ACTION: @anssiko to add this v2 feature provisionally to the Charter 2018

Since the draft Charter 2018 links to examples of features that may be integrated [into Presentation API Level 2] -- including this issue -- we agreed at the closing Revisit Charter 2018 F2F session that we do not need to explicitly enumerate v2 features in the charter.

[anssiko]

The plan is to recharter CG to incubate https://mfoltzgoogle.github.io/remote-window-api/explainer.md further.

[anssiko]

ACTION: @anssiko to amend the CG charter accordingly.