Repository navigation
Add always-on-top explainer - #163
Conversation
michaelwasserman
left a comment
michaelwasserman
left a comment
There was a problem hiding this comment.
Mostly lg, but please consider addressing some comments first. (not all are blocking, feel free to ack and punt/ignore).
|
|
||
| ## 2. Use Cases & User Motivation | ||
|
|
||
| There are several key productivity and utility use cases where users benefit from persistent, always-on-top windows: |
There was a problem hiding this comment.
All three use cases mention presenting the window on top of full-screen content. While that might be a fairly strong requirement, would an implementation that z-ordered these windows beneath full screen content be adequate?
Should the explainer mention anything about how macOS WMs switch spaces when content enters fullscreen, and how these windows should either move between spaces, or remain on the original space?
| * **Permission Requirement:** This capability is gated behind the `window-management` permission. If this permission has not been granted by the user, the `alwaysOnTop` request is silently ignored, and a standard popup window is created instead. | ||
| * If `true` and the required permission is granted, the OS-level window manager is instructed to keep this window pinned above other non-always-on-top windows. | ||
| * **Z-Ordering of Multiple Windows:** The relative z-ordering between multiple concurrent always-on-top windows is left to the User Agent or the underlying operating system. For example, UAs may order them based on which window was most recently focused. | ||
| * **UA-Defined Limits:** To preserve usability, browsers (User Agents) may enforce implementation-specific limits. For example, UAs may restrict origins to a single active `alwaysOnTop` window at a time, or make it mutually exclusive with other types of Picture-in-Picture (PiP) windows. The UA may also restrict the size of the always-on-top window. |
There was a problem hiding this comment.
This is interesting and perhaps surprising. I think it merits additional detail in the security section, or elsewhere that might talk about abuse mitigation, or secure usability protections
| * Requiring both the requestable `window-management` permission and explicit user activation constitutes a very high bar that prevents untrusted or malicious sites from spamming pinned windows. | ||
| * **Move & Resize Restrictions:** To prevent abuse scenarios like a window programmatically tracking the cursor or expanding to obscure critical OS interface elements, synchronous APIs that manipulate window bounds (`moveTo`, `moveBy`, `resizeTo`, `resizeBy`) are subject to strict UA rate limits and transient user activation checks, analogous to the mitigations applied to Document Picture-in-Picture windows. | ||
| * **Focus Stealing Protections:** Always-on-top windows must not be permitted to aggressively force focus back to themselves when the user interacts with other applications. | ||
| * **Explicit User Affordance & Easy Dismissal:** The browser and operating system window frames must provide clear, un-spoofable user controls to dismiss the window at any time. |
There was a problem hiding this comment.
I wonder how this pairs up with unframed windows, but maybe the considerations are different there, since it's also specific to isolated web contexts, IIUC
|
|
||
| ### Native Packaging (Electron / NW.js) | ||
|
|
||
| Currently, web developers building tools requiring persistent always-on-top capabilities (such as companion note-taking apps, trading dashboards, or screen annotation widgets) are forced to wrap their applications in desktop runtimes like Electron just to access APIs like `BrowserWindow.setAlwaysOnTop()`. Providing this capability natively on the web platform bridges a critical capabilities gap, eliminating the need to bundle dedicated native runtime binaries. No newline at end of file |
There was a problem hiding this comment.
This is a great point, it might even merit a brief mention earlier in the doc
|
|
||
| --- | ||
|
|
||
| ## 5. Security & Privacy Considerations |
There was a problem hiding this comment.
Please plan to add a corresponding security_and_privacy_ companion markdown file, using the latest W3C questionnaire template
|
Per offline discussion, I'll resolve the rest of the comments in a followup PR |
SHA: d7c46f7 Reason: push, by michaelwasserman Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
2 participants
Adds explainer for always-on-top feature. Copied from https://github.com/steimelchrome/always-on-top-explainer/blob/main/explainer.md