`alwaysOnTop` in `window.open()` spec mentor request

8 views
Skip to first unread message

Tommy Steimel

unread,
Jul 13, 2026, 3:14:00 PMJul 13
to spec-mentors
Hi spec-mentors@,

I recently filled out the form for a spec mentor but now I'm seeing on here that form automation is broken so I'm sending the request directly/manually here. The feature adds an `alwaysOnTop` boolean to the `window.open()` API that opens the popup in an always-on-top window. This is gated behind the window-management permission.


Thanks!
Tommy

Reilly Grant

unread,
Jul 13, 2026, 3:38:46 PMJul 13
to Tommy Steimel, Mike Wasserman, spec-mentors
I'm worried that this proposal indicates a failure of the document picture-in-picture feature if Meet (I'm reading between the lines here) is requesting the ability to create an arbitrary always-on-top window instead. The "alternatives considered" section should probably elaborate more on where picture-in-picture falls short and why it cannot be improved to solve the underlying use case.

If he's available I nominate @Mike Wasserman to mentor this given his familiarity with window management.
Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome


--
You received this message because you are subscribed to the Google Groups "spec-mentors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spec-mentors...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/spec-mentors/CAGyVZ8%2B%3Dhi432wdgAC59KTw4Z%3D_uNY%3Da996f6wU%2BRnM3LQV3Tw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

Tommy Steimel

unread,
Jul 13, 2026, 4:22:41 PMJul 13
to spec-mentors, Reilly Grant, spec-mentors, Tommy Steimel, Mike Wasserman
That's a fair criticism. The main problem of document picture-in-picture for their use case is that they want the always-on-top window to continue to exist when the opener is closed, and document picture-in-picture windows explicitly disallow that[1]. The mental model of document pip windows is that they are an extension of the page (or a view of the page while the page is backgrounded), while for this proposed API the mental model is that it's its own full/independent application (e.g. loading it's own URL rather than being a blank HTML document and outliving the opener) which more fits with the idea of a window.open popup. Though they are obviously similar in that they both put arbitrary HTML content in an always-on-top window.

[1] https://wicg.github.io/document-picture-in-picture/#close-on-destroy

On Monday, July 13, 2026 at 12:38:46 PM UTC-7 Reilly Grant wrote:
I'm worried that this proposal indicates a failure of the document picture-in-picture feature if Meet (I'm reading between the lines here) is requesting the ability to create an arbitrary always-on-top window instead. The "alternatives considered" section should probably elaborate more on where picture-in-picture falls short and why it cannot be improved to solve the underlying use case.

If he's available I nominate @Mike Wasserman to mentor this given his familiarity with window management.
Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome


On Mon, Jul 13, 2026 at 12:14 PM Tommy Steimel <ste...@chromium.org> wrote:
Hi spec-mentors@,

I recently filled out the form for a spec mentor but now I'm seeing on here that form automation is broken so I'm sending the request directly/manually here. The feature adds an `alwaysOnTop` boolean to the `window.open()` API that opens the popup in an always-on-top window. This is gated behind the window-management permission.


Thanks!
Tommy

--
You received this message because you are subscribed to the Google Groups "spec-mentors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spec-mentors+unsubscribe@chromium.org.

Reilly Grant

unread,
Jul 13, 2026, 4:36:08 PMJul 13
to Tommy Steimel, spec-mentors, Mike Wasserman
That's unfortunate because I think that's something Progress Notification could potentially have solved. Can you expand on this use case more in the explainer?
Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

On Mon, Jul 13, 2026 at 1:22 PM Tommy Steimel <ste...@chromium.org> wrote:
That's a fair criticism. The main problem of document picture-in-picture for their use case is that they want the always-on-top window to continue to exist when the opener is closed, and document picture-in-picture windows explicitly disallow that[1]. The mental model of document pip windows is that they are an extension of the page (or a view of the page while the page is backgrounded), while for this proposed API the mental model is that it's its own full/independent application (e.g. loading it's own URL rather than being a blank HTML document and outliving the opener) which more fits with the idea of a window.open popup. Though they are obviously similar in that they both put arbitrary HTML content in an always-on-top window.

[1] https://wicg.github.io/document-picture-in-picture/#close-on-destroy

On Monday, July 13, 2026 at 12:38:46 PM UTC-7 Reilly Grant wrote:
I'm worried that this proposal indicates a failure of the document picture-in-picture feature if Meet (I'm reading between the lines here) is requesting the ability to create an arbitrary always-on-top window instead. The "alternatives considered" section should probably elaborate more on where picture-in-picture falls short and why it cannot be improved to solve the underlying use case.

If he's available I nominate @Mike Wasserman to mentor this given his familiarity with window management.
Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome


On Mon, Jul 13, 2026 at 12:14 PM Tommy Steimel <ste...@chromium.org> wrote:
Hi spec-mentors@,

I recently filled out the form for a spec mentor but now I'm seeing on here that form automation is broken so I'm sending the request directly/manually here. The feature adds an `alwaysOnTop` boolean to the `window.open()` API that opens the popup in an always-on-top window. This is gated behind the window-management permission.


Thanks!
Tommy

--
You received this message because you are subscribed to the Google Groups "spec-mentors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spec-mentors...@chromium.org.

Mike Wasserman

unread,
Jul 13, 2026, 5:16:36 PMJul 13
to Reilly Grant, Tommy Steimel, spec-mentors
Tommy and I chatted briefly and informally about this proposal; unfortunately, that chat history expired.
I'm happy to volunteer as a spec mentor here, as I've been helping with Additional Window Controls enhancements to the window-management spec.

Reilly's initial feedback is poignant. The explainer really needs to spell out the use case workflows that make PiP insufficient. How does disassociating the lifecycle of an always-on-top window from the parent 'background' tab benefit users? Sharing more concrete UX patterns not possible via PiP would help. Are any other features needed to make this work (e.g. detecting whether the request was honored, focusing the parent and closing oneself like PiP's browser action, z-ordering behaviors among always-on-top windows, UAV2 transient activation consumption relation to the Popups and Redirects content setting, etc.)? FWIW, window.open()'s feature string is fraught with ergonomic issues, but that doesn't truly block extending it here.

Reilly, can you clarify how Progress Notification might have helped here?

Tommy, lmk if you'd like to chat about how the use case requirements can more clearly articulate why existing solutions aren't sufficient.
Mike

Reilly Grant

unread,
Jul 13, 2026, 6:23:44 PMJul 13
to Mike Wasserman, Tommy Steimel, spec-mentors
One effect of an active Progress Notification could've been for the browser to behave as if the site had an active document, even though there wasn't one. At the time we were thinking about this in the context of Shared Workers but it could equally apply to a Document Picture-in-Picture window.
Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

Reply all
Reply to author
Forward
0 new messages