Feature-parity with app.window.create(..., { frame: 'none' })
available in Chrome Apps platform
#48
Labels
enhancement
New feature or request
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 erstwhileapp.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.
The text was updated successfully, but these errors were encountered: