Contact emails

[email protected], [email protected]

Explainer

https://github.com/bradtriebwasser/fullscreen-popup/blob/main/EXPLAINER.md

Summary

Adds the ability to open a popup directly to full-screen.

Adds an additional windowFeatures
<https://developer.mozilla.org/en-US/docs/Web/API/Window/open#windowfeatures>
parameter to the window.open()
<https://developer.mozilla.org/en-US/docs/Web/API/Window/open> JavaScript
API which allows the caller to open a popup directly to full-screen on the
display that would contain the popup (based on screenX
<https://developer.mozilla.org/en-US/docs/Web/API/Window/open#left>/screenY
<https://developer.mozilla.org/en-US/docs/Web/API/Window/open#top>). This
eliminates the need for the developer to manually transition a popup into
full-screen which could
<https://github.com/bradtriebwasser/fullscreen-popup/blob/main/EXPLAINER.md#spec-notes>
require a new user activation
<https://html.spec.whatwg.org/multipage/interaction.html#tracking-user-activation>
signal.

Blink component

Blink>Fullscreen
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFullscreen>

Motivation

Sites cannot open full-screen windows without multiple user gestures
<https://github.com/bradtriebwasser/fullscreen-popup/blob/main/EXPLAINER.md#spec-notes>.
This particularly restrains web applications that launch full-screen
content on another display (via the window management
<https://w3c.github.io/window-placement/> API) by requiring multiple user
interactions which degrades user experience.

Initial public proposal

https://github.com/w3c/window-placement/issues/7

TAG review status

Not yet requested

Risks
Interoperability and Compatibility

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/714)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/101)

Web developers: Positive https://github.com/w3c/window-placement/issues/7
https://github.com/w3c/window-placement/issues/98#top
https://github.com/w3c/window-placement/issues/92

Other signals: none

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

Considered low risk since this is introducing a new API that will affect
desktop platforms only.

Debuggability

This feature utilizes the existing windowFeatures string parameter in
Window.open() <https://developer.mozilla.org/en-US/docs/Web/API/Window/open>
and does not modify any structured (i.e. WebIDL) API surface. This feature
will integrate with existing fullscreen APIs which developers can use for
debugging (document.fullscreenElement, fullscreenchange, and
fullscreenerror, etc.).

Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
?

Not yet. Tests will be added during prototyping. Web platform tests are
limited to single display environments, so testing fullscreen popups across
displays will not be possible in web platform tests.

Flag name

FullscreenPopupWindows

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1142516

Launch bug

https://launch.corp.google.com/launch/4211164

Estimated milestones

Desktop: M111

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6002307972464640

This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEkiBsw786JqX%3DL8Z%3DrZRUsd-fCCkf0ggjMNpPuaf7QmZ3hjhw%40mail.gmail.com.

Reply via email to