DisplayModeType Borderless

[ghost]

Some applications do not require the OS window.
For example on Photoshop has border less mode for its UI to make most use of screen area.
This is different from fullscreen because in this only the OS window status bar is hidden.

Edit:
The critical buttons should still be there (ie close/minimize) , but the rest of the window chrome should made border less and letting the app draw there.

[dominickng]

This seems like a duplicate of #659, and that thread summarises why the major browser vendors are highly unlikely to add support for such a display mode.

[ghost]

Dont close this yet.
Since the threat is about the close and open button and minimize/maximize being hidden, We should keep the close and open buttons there, but remove the rest of the wasted space. This seems reasonable and does not harm while giving extra space.

[dominickng]

What is the "rest of the wasted space"? If you have a title bar with the standard close/minimize/maximise buttons (or whatever is the per-platform standard), what space can then be removed that isn't already gone in standalone mode?

[ghost]

Here is what I mean:
https://imgur.com/a/Ew4KjH7

The area in rectangle should remain, but the area that is scribbled should be gone in border-less mode. It is safe and allows for in app tabs while giving the developer more screen space.

[marcoscaceres]

https://imgur.com/a/Ew4KjH7

Ok, but is there apps that actually do that? Seems to totally break OS conventions (hence you having to scribble out part of the UI)

[ghost]

Yeah, for example in apps like photoshop, a tabbed experience provided by the app is better.
There are no apps that I know of that do this because on Windows it is easily possible to run border less.
On PWA's because security aspect needs to be taken into account, leaving the main buttons is enough, while the rest of the os window chrome is removed if border less mode is required by the app.

Or if it breaks it, the browser's standard open/close buttons could be there to ensure no abuse happens.

[ghost]

He is is an app I think would benefit a lot from this mode: https://editor.construct.net/r98/index.html
The have tabs and buttons. The os chrome makes it ugly for the app to navigate.

[g-ortuno]

I don't think it looks thaaat bad:

[dominickng]

Removing the top bar also makes it impossible to drag the app window to reposition it on the screen on Chrome OS, which seems like a bigger usability problem.

[marcoscaceres]

Another problem is that there is no guarantee a to where the OS buttons would end up. For instance, MacOS puts the close buttons on the left, while windows does it on the right... and this could change from one OS version to another... and could be even more inconsistent on mobile, where close buttons are generally not a thing.

[ghost]

Can there be a standard drawing API for this than? Because we really want custom looking tabs in our app and this restriction is making the flow irregular? At-least for developers that do cross platform testing, a bit of control is necessary. We can always have this, but a bit more control would be beneficial for the UX.

Removing the top bar also makes it impossible to drag the app window to reposition it on the screen on Chrome OS, which seems like a bigger usability problem.

Add some margin to the buttons where it will still be drag able. This is an easily fixable problem if we take some minor precautions.

Another problem is that there is no guarantee a to where the OS buttons would end up. For instance, MacOS puts the close buttons on the left, while windows does it on the right... and this could change from one OS version to another... and could be even more inconsistent on mobile, where close buttons are generally not a thing.

Its a progressive web app. We as developers take care of the cross platform support, but choice should be given to us to make more creative use of this space. For all major OS's testing is done.

If everyone agrees that they are willing to add this. With virtually zero risks I can provide a better way to deal with all the edge cases.

All of this could be taken care of by informing the application if buttons are left to right or right to left. Adding some margin after the last button to allow for guaranteed dragging. Than developers who decide that they can deal with the complexity can comfortably do it.

And at last an api for dragging could be introduced to dom element ia in app that can make window drag able. This could only work when app is installed to prevent abuse on webpages.

We only have a standalone application because of this.

I don't think it looks thaaat bad:

Don't you think the UX could be improved if tab was at the top. While moving my mouse swiftly, I usually adjust the horizontal position of my cursor while aiming to hit the top pixel of screen to switch between tabs. Try using internet explorer. Also on Chrome OS you dont have window maximized. For most productivity suites, you have the window maximized and that is when flaws start becoming apparent.

[mgiuca]

There are heaps of other edge cases to consider here.

• What if the operating system doesn't put the 3 buttons on the top-left or top-right?
• What if the operating system uses that title-bar space for other business? We do on Chrome OS, in various ways: we show the origin during window-open (that is a security requirement). We show permission icons (also a security requirement), which can display arbitrarily many icons. We show extension icons.
  • Because a lot of these are security requirements, we'll be very afraid to let the app draw into the title bar space, because then it would allow the app to spoof those security features.
• What if the operating system doesn't have a concept of a title bar at all? Mobile OSes satisfy this, as to tiling window managers on Linux.
• What if the operating system doesn't give us access to draw into the top bar space at all? e.g., Linux (though on Linux we'll probably have to draw an entirely custom title bar, due to this).
• What if the user agent wants to add more UI into the title bar in a future version (e.g., we are considering adding a "Back" button to the top-left in Chrome).

Arguably, the answer to many of these is that "display: borderless" is a best-effort thing. If the host platform supports overdraw into the title bar, then we let the application overdraw, otherwise we don't, and the application just has to sort it out. If we do allow it, we then need APIs to communicate exactly which rectangles of the title bar are available for overdraw, which can change dynamically (e.g., as the "Back" button pops in and out). And then developers need to test against many different platforms, including those that do and do not allow overdraw.

And at last an api for dragging could be introduced to dom element ia in app that can make window drag able. This could only work when app is installed to prevent abuse on webpages.

That's a huge amount of complexity with lots of edge cases. We lived through this with Chrome Apps where we (for some reason) encouraged developers to create a borderless window and provide their own title bar UI, using a dragging API. We are explicitly afraid of the complexity in the window-dragging space. Again, more territory for developers to mess up and create a broken experience on some platforms.

This is potentially doable (and will be something that apps can really take advantage of), but introduces massive complexity (for user agents and developers), compat issues (if developers do a poor job of testing, for example drawing over parts that are free in Windows but not macOS, making for a bad user experience on other platforms and boxing us into a corner with regards to future UI changes) and potential security risks (due to our use of the title bar for spoofing).

This may be something we try to tackle some day, but it's certainly not trivial, and not something I think we want to look at any time soon (with heaps more pressing issues to deal with).

[mgiuca]

I just realised that @ghost is literally a ghost (deleted user account), not a username.

In that case, (and due to what I've written above), closing this issue for the foreseeable future.

[Ayplow]

I by no means have a security background, but if the issue is with apps spoofing security features, then what is the problem with treating the 'borderless' mode as a high-level permission? Provide a maximise/minimise/close api, and if the user gives permission, then the application is trusted to handle it properly.

In that case,

What if the operating system doesn't put the 3 buttons on the top-left or top-right?

What if the operating system uses that title-bar space for other business?

The user has explicitly permitted the applications request for that 'business' to be hidden, so it would be reasonable to support. Alternatively, if this platform was stringent about that display, we already have a precedent for how to handle it - fallback to standalone. Then the application would be able to respond the same way as if the user denied the borderless permission.

What if the operating system doesn't have a concept of a title bar at all?

I'd consider mobile OSs not to support the borderless mode - their 'titlebar' is the application switcher that they can close the window with. Again, I dont see an issue with this decision being made by the user agent.

What if the operating system doesn't give us access to draw into the top bar space at all?

I do think that drawing on top of an existing border is too complex to make generic - The request would be for the chrome/frame/border to be completely hidden, allowing the application full control of the content displayed in its 'area'.

What if the user agent wants to add more UI into the title bar in a future version

With said bar effectively being disabled, users would expect it to be dependent on the app. It could be implemented at the application's discretion

Also, I'd have to be in support of a drag handle API without this feature too - there are quite a few native apps that allow dragging sections other than the titlebar.

[mgiuca]

From a security standpoint, a permission doesn't necessarily make us feel safer. We often see proposals for new permissions that amount to "Do you want to give this application permission to show potentially misleading security UI in the future?" and those prompts are extremely difficult to word in such a way that the user will understand what they are granting, since the benefits and drawbacks are not obvious to someone who doesn't understand the security consequences. Many users will just grant the permission, not seeing any downside, and then at a later time, they may be tricked into thinking they are somewhere that they're not.

Outside of security: I still have great concerns around portability and usability. If we give a web app the ability to draw into the system-supplied title bar, it is basically impossible to make use of that ability without knowing at least something about the host OS, such as whether it draws its caption buttons on the left or right side of the window, and it's impossible to make it look good without knowing something about the style the host OS uses (such as does it have flat buttons or 3D-looking buttons). This will lead sites down a path we try very hard to avoid: detecting the top 1 or 2 host operating systems and integrating well with those, and then ignoring the rest. I guarantee if we allow this, there will be some sites that look good on Windows 10 and trash everywhere else (up to and including drawing over the top of caption buttons), and some other sites that look good on the latest macOS and trash everywhere else. Our mission as web platform designers is to create an abstract interface that allows sites not to care about what the host OS is at all, and let the user agent make all of those decisions on behalf of the site.

[Ayplow]

Why do these security issues not apply to mobile PWA implementations? The current 'fullscreen' mode lets the application draw to the entire screen.

As for consistency, I think you're right - there isnt really any way to get out of targeting specific platforms if an application wants to look like a 'native' window and use this display mode. However I would imagine it being used with applications with a specific idea of how they want their app to open and close - similar to android apps with an 'exit' button in the sidebar (Or a 'Do you really want to leave your dying villagers' popup in a game). Right now there is now way to make that interaction unified.

[AmossGuy]

This is the same thing as #847.

[mgiuca]

Yes, sort of.

#847 is specifically about giving windows the option to draw to a user-agent controlled space in the title bar, not giving them complete control over the contents. It would still show the UI that we're drawing.

That is the most viable path forward for this feature request.