w3c / window-management

Window Management API
https://www.w3.org/TR/window-management/
Other
95 stars 25 forks source link

Feature-parity with `app.window.create(..., { frame: 'none' })` available in Chrome Apps platform #48

Open exikyut opened 3 years ago

exikyut commented 3 years ago

Hi,

Arrived here through the https://www.chromium.org/chrome-apps migration doc via https://bugs.chromium.org/p/chromium/issues/detail?id=897300. I spotted a reply (buried amongst the bugdroid soup :) asking for feedback to be posted to GitHub in response to a question someone else asked in that thread, so I'll take that as my cue to put this here.

The Chrome Apps platform provide{d,s} the ability to create windows that have no frame or border by specifying frame: 'none' in CreateWindowOptions (current docs: https://developer.chrome.com/docs/extensions/reference/app_window/, old docs: http://web.archive.org/web/20201029101524/https://developer.chrome.com/apps/app_window). The ability to use this API will completely go away in a few months once Apps support is (at length) removed from Chrome.

While a somewhat obscure use case (and perhaps(?) outside the original scope of intended use), some time ago I realized this could be used to implement hovering-sidebar-like experiences for desktop Chrome, employing a simple vertical border along the edge of the window to clearly delineate where the popup window ended and whatever was underneath began. Such experiences could be extended to Chrome extensions (such as, for example, those allowing for bookmark or tab management) by a bit of fiddly but manageable message-passing between a "shell" or empty app that simply opened a frameless window, and a main extension that did all the heavy lifting.

Sadly, I think it was a couple of weeks after I thought of the above idea that I discovered Apps' deprecation status, and that kinda killed my motivation to pursue the idea at the time. Was very disappointing FWIW.

Normal Chrome windows impose... *measures* ...72 pixels of mandatory fill at the top of the screen (and let's say at least 1.5x that in HiDPI-ish modes), while those opened using the chrome.windows.create(..., type: 'popup') API available to extensions still retain native window borders that also consume vertical space. The native controls are created by the OS on the assumption that a) they are useful, and b) that they will be removed (hidden) if appropriate or beneficial to the context. The erstwhile app.window Apps API extended this notion to the world of HTML5/JS, and enabled a sort of mini-Electron tied to Chrome that didn't require you to have a separate Blink runtime hoarding its own pile of RAM. It was neat. (One of Electron's main points is that it can create borderless windows, allowing the same level of UI customization this API provides.)

So, alongside the medley of random applications out there using frameless/borderless windows in kiosk-like environments and other interesting situations, I would firmly +1 the capability to open borderless windows in appropriately sanctioned contexts, such as extensions, and possibly also scenarios where a user has used web platform "install" functionality on a PWA or similar experience (where such experiences already hide the URL bar in mobile environments, which perhaps offers some security and UI consistency precedence).

In closing, I'm cognizant of the massive potential for phishing and general tomfoolery possible with a capability like this - the kind that gets nice features with lots of potential killed with sufficient precedent that they never come back - so I'm happy to just repeatedly push the "this is a nice idea IMO!" button occasionally and let everyone else argue about how to do it securely :)

Maybe the relevant team members associated with the API rollout could share any interesting security issues (fraudulent use, etc) that occurred "in the wild" on the Chrome Web Store.

inexorabletash commented 3 years ago

Thank you for the details of your use case! Borderless windows are on the list of things to investigate for use in, as you phrase it "appropriately sanctioned contexts".

While not providing borderless windows, you should check out this work: https://github.com/WICG/window-controls-overlay/blob/main/explainer.md - we expect this to unlock some (but certainly not all) of the scenarios that borderless would enable.

michaelwasserman commented 2 years ago

Indeed, Window Controls Overlay is the most similar capability making its way to the web platform at the moment. Still, this seems like a reasonable enhancement request for a Window Placement API that may merit future consideration.