This explainer aims to make mutli-screen experiences more flexible and convenient for users of web applications.
The Window Management API provides information about the device's connected screens, and allows web applications to open and position windows or request fullscreen on any of those screens.
A recent enhancement enabled web applications to place fullscreen content on a specific screen and place a new popup window on a separate specific screen, with a single user interaction.
A proposal for Creating Fullscreen Popup Windows would enable web applications to open a new fullscreen window on a specific display, with a single user gesture. That proposal explicitly consumes transient activation, to limit fullscreen popup creation, even when the user agent is configured to permit popup window requests.
Advanced web applications require additional flexibility, beyond recent enhancements and proposals, to conveniently initiate additional multi-screen experiences. Currently, each fullscreen request requires a separate user interaction, which adds undue user friction in some specific use cases.
- Virtual Desktop app opens a fullscreen window for each screen
- Virtual Desktop app toggles fullscreen in existing windows for each screen
- Slideshow app presents fullscreen slides and speaker notes on separate screens
- Financial app launches a fullscreen dashboard encompassing multiple screens
The goal of this document is to enable scripts with the multi-screen window-management permission to present content throughout the entirety of a multi-screen device's visual output, from a single transient user activation.
This builds on Initiating Multi-Screen Experiences to solve a more general pattern, beyond the highly specific scenario explored there.
The proposal aims to enable executing a windowing action on each screen of a multi-screen device with a single user interaction, i.e.:
- Open a popup window on each screen, potentially a new fullscreen popup
- Make an existing window fullscreen on each screen, aided by capability delegation
- Some mix thereof, e.g. one fullscreen and two popups, given three screens
The design extends Tracking User Activation with additional state specific to powerful features. This enables a single transient activation to permit multiple API requests pertaining to window-management, which would otherwise consume a singular state.
One possible shape for this proposal tracks a list of powerful feature types consumed alongside the Window's activation timestamp. The list is initially empty, and cleared on activation notification.
The algorithm to consume user activation would take an optional type to consume. When window-management is specified by script allowed to use window-management, the algorithm would only set the last activation timestamp to negative infinity when the list contains as many window-management entries as the number of screens connected to the device; otherwise it would append a window-management entry.
The steps for checking transient activation would similarly take an optional type. When window-management is specified by script allowed to use window-management, the algorithm would consider the list of types consumed against the number of screens connected to the device, in addition to the last activation timestamp .
The following API algorithms would would be modified to consume user activation state pertaining to window-management:
Element.requestFullscreen()Window.open()Window.postMessage()(when initiating delegation of the fullscreen capability)
Earlier work added a very narrowly scoped internal slot on Window modeled after last activation timestamp, to conditionally permit a popup window after fullscreen is requested on a specific screen. That is no longer necessary with this more general proposal, and can be removed.
This feature can be used after the site successfully requests detailed screen information. Script could now request fullscreen and open fullscreen popups on other screens, in a single event listener:
initiateMultiScreenFullscreenButton.addEventListener('click', async () => {
// Make the current window fullscreen on its current screen:
const currentScreen = window.screenDetails.currentScreen;
await document.documentElement.requestFullscreen({screen : currentScreen});
// Open a fullscreen popup on each other screen.
for (let s of window.screenDetails.screens) {
window.open(url, '_blank', `popup,fullscreen,` +
`left=${s.availLeft},top=${s.availTop},` +
`width=${s.availWidth},height=${s.availHeight}`);
}
});Given a set of existing non-fullscreen popup windows opened to present content on each screen, script could delegate fullscreen to each of those windows from a single event listener:
resumeMultiScreenFullscreenButton.addEventListener('click', async () => {
// Delegate a fullscreen request to each existing cached window.
for (let s of window.screenDetails.screens) {
s.cachedPopup.postMessage('resumeFullscreen', {targetOrigin: origin, delegate: 'fullscreen'});
}
});A similar delegation technique would allow a single event listener to rearrange multiple existing fullscreen windows between screens.
The UserActivation interface exposes activation state to script, and could be extended to offer a reasonable feature detection surface for the updated User Activation Tracking model.
This feature enables sites to perform multiple window management actions from a single user activation. This may exacerbate some documented Window Management Security Considerations, also considered in Initiating Multi-Screen Experiences.
This feature does not expose any information to sites, and there are no privacy considerations to note beyond those already documented in the Window Management Privacy Considerations section.
- Permit N
Window.open()calls on a device with N screens- This does not satisfy the goal of also 'resuming' fullscreen
- Introduce a new API to support multi-screen fullscreen
- This may be a desirable long-term path, but it is not nearly as tractable
- Gate window-management actions by activation, rather than consuming it
- This allows unbounded actions from one gesture, which is more prone to abuse
- Tokenize access to individual screens
- Enforces coherent initial placement, but popups can move without gesture
- Introduces substantial complexity, particularly when delegating fullscreen
- Add more feature-specific internal slots, like earlier work
- Less encapsulated and more complex than enhancing user activation tracking