-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Local Presentation API to enable child-window presentation documents #347
Comments
For reference, see related discussion at TPAC |
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.
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. |
This is an important item from our perspective, as it addresses specific challenges we have had with adoption of the Presentation API. |
Wrote up a brief explainer for F2F discussion. https://mfoltzgoogle.github.io/remote-window-api/explainer.md |
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 |
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. |
The plan is to recharter CG to incubate https://mfoltzgoogle.github.io/remote-window-api/explainer.md further. |
ACTION: @anssiko to amend the CG charter accordingly. |
The updated link for the explainer is here (I renamed the repository to better reflect the proposed API). https://github.com/mfoltzgoogle/local-presentation-api/blob/gh-pages/explainer.md |
As a reminder, the CfC to incubate the "local presentation mode" in the Second Screen CG is open until 20 June 2018. See the CfC sent to the public-webscreens on 21 May 2018. To support this CG charter amendment, simply add your 👍to webscreens/cg-charter#18 |
@mfoltzgoogle volunteered to update the status in this issue briefly here. Per our resolution, I started a CfC to drop "Local Presentation Mode" from the CG Charter scope, see webscreens/cg-charter#26 |
Summary of developments since this issue was first filed: The primary use case that was in mind when the explainer was written was to allow presentation applications to make use of multiple displays. These applications wish to present slides or other content on the secondary display and controls and speaker notes on the primary display. The Presentation API doesn't allow the two documents to share state which was a blocker. If the secondary display is a wired attached display, then the Multi-Screen Window Placement API handles this use case by giving the application the ability to place a new window on that secondary display. The Fullscreen Companion Window makes the flow even simpler than what was proposed here (not requiring additional browser dialogs). If the secondary display is a wireless display, the application can open the presentation content in a new tab, control it by cross-window messaging, and then invoke the Tab Self-Mirroring API to project it to the secondary display. As the core use cases are being handled by ongoing work in the community and working groups, we don't plan on pursuing this feature any further. I plan on closing this out once the CG charter is updated to reflect that it's no longer a work item for the group. |
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.
There may be other use cases as well.
In my thinking there could be two avenues to explore:
The text was updated successfully, but these errors were encountered: