Add borderless mode explainer #73
Conversation
|
Hi @sonkkeli Thanks for writing this up. I had a read over it. I will do a drive-by and give some in-line comments in a bit, but my overall thoughts is that the proposal makes sense, the write-up needs to be less Chrome and ChromeOS-focused. Understanding that this is being primarily driven by ChromeOS, we still need to write an explainer that considers the API in the wider web ecosystem, given that it is being proposed as a W3C standard. I'll put direct comments in-line. I think a lot of this text could go into an internal design doc (public, if desired). Note that it is still OK to reference specific browsers and OSes in explainers, but they need to be by way of example, not the exclusive focus of the document. |
borderless/explainer.md
Outdated
|
|
||
| ### 4. Leveraging Window Management permission for borderless | ||
|
|
||
| In order for the borderless mode to activate, the app needs to have Window |
There was a problem hiding this comment.
It makes me uncomfortable tying these two permissions together.
Borderless is a much scarier permission than management, due to the spoofing risk. I would not want every app I grant management permission to to magically get borderless permission as well.
There was a problem hiding this comment.
The permission design has been discussed and approved by security. I think the differentiation here is that it's only supported for isolated web apps, so providing the window management permission on its own would still not enable the feature.
There was a problem hiding this comment.
Thanks, I've completed the review.
I think most of my comments are basically around generalizing this for an audience of other browser vendors and W3C folks to understand what this means as a standard, rather than simply how it fits into ChromeOS plans. If there isn't one already, I think having a separate doc for ChromeOS implementation details (like moving permissions to the shelf, app settings, etc) would be good, instead of explaining those details here in a doc that's intended for a wider audience.
Beyond just the scope of the doc, I also thought some more about the permission model and whether it makes sense to be tied to the AWC and JavaScript APIs, and the UI for enabling it.
borderless/explainer.md
Outdated
| JavaScript: | ||
|
|
||
| ``` | ||
| const screenDetails = await window.getScreenDetails(); |
There was a problem hiding this comment.
I have a lot of reservations about how granting the permission (in the unmanaged case) works from an API and UI perspective.
- There's a weirdness here about having to use JavaScript to ask for permission to use a feature declared in the manifest. This suggests further to me that it shouldn't be tied to the Window Management API permission.
- What happens if the permission has not yet been granted or denied? (Presumably, we fall back to the next display mode in the chain, e.g. standalone., which means in the VDI case showing a double-title-bar.) Is this acceptable UX?
- What happens at the instant the permission is granted? Do we expect the window's title bar to disappear upon being given permission? Or does it just change upon the next reload?
- My biggest concern: If the window simply never showed the native title bar, it would be just a fact that this app doesn't have certain controls, and as you say below, there will be alternative ways to get to those features. However, having the app first appear with the native title bar, then a permission prompt being granted causing the title bar to disappear, leads the user to wonder where it went and how to get it back. I don't think it's good to provide UI (in the form of the permission prompt) to make it go away but no way to get it back (other than digging in app settings to revoke the permission). We should address this and possibly provide a way to "reveal" the hidden title bar.
If we're going to show the native title bar to the user on first run anyway, and the user will have to take action to make the native title bar go away, we could essentially make the "permission" a part of the UI instead of something you are prompted for. This is basically the same thought process we went through for WCO: if you're going to start with the full title bar shown, and the user will explicitly give permission to hide it, why not just make that permission a button in the UI, and why not make that button a toggle so they can get it back using the same mechanism they used before.
You could then show an animation when the user toggles the title bar away of the title bar collapsing into the system shelf (indicating where to go to find the controls), or perhaps just collapsing into a small clickable zone in the corner which lets you get it back.
None of this precludes having an admin policy to enable borderless by default. But in the unmanaged case (or managed case where the admin hasn't set that policy), it would be good to think about the UX of how the user grants and un-grants this, and it may make sense for it to not be a normal permission prompt.
There was a problem hiding this comment.
-
This could be prompted on window onload.
-
Yeah it displays standalone until we have the permission.
-
It immeadiately updates the window from standalone to borderless without having to refresh manually. If we toggle the permission from the settings, then it shows the default "Reload" infobar (which is default behaviour for toggling any other permission as well).
-
(and the rest) I think here we have trusted on the first version not being available to other but the trusted VDI partners who we'd trust to not do evil things. This is because IWAs in general are not available in the open web yet. This should be something to take into consideration in the future though if extending it for non-partners. Do you think that should be something to already discuss in the explainer despite it would probably be implemented much later?
There was a problem hiding this comment.
- Is not entirely satisfying to me but I understand it would work mechanically. Having a permission prompt that doesn't actually give the app any new API capabilities, it just makes something you declared in your manifest start working, doesn't feel like a permission to me. It feels like a UI setting. (Again, that's how WCO was designed. We could have made you do a permission prompt to activate WCO but we designed it as a UI setting instead.)
- OK.
- OK.
- I don't think that addresses the question. I asked about what if the user grants the permission (which causes the window UI to disappear) and then wants to get it back again. There's no "evil thing" happening here, it's just a natural thing for a user setting to be reversible. The fact that, upon granting the permission, you will be hiding the entire permission granting UI somewhere else, means it can be tricky for a user to try and undo that change.
These things can probably be sorted out after the explainer lands in the repo, so I won't block the review on it. But I do want to keep talking about what this UI looks like in the non-enterprise non-VDI case. We should have a design in mind that scales beyond a set of trusted partners.
There was a problem hiding this comment.
I already raised this Q up to our PM so we'll keep working on this. I will leave these comments open here.
sonkkeli
force-pushed
the
borderless-explainer
branch
from
2581853
to
1159b45
Compare
|
Hey Matt and thanks for all the comments, they made the explainer much better I think. There's still a few unresolved comments with some open Qs but in general I think it is ready for another PTAL . :) |
sonkkeli
force-pushed
the
borderless-explainer
branch
from
ad17202
to
4163896
Compare
borderless/explainer.md
Outdated
| JavaScript: | ||
|
|
||
| ``` | ||
| const screenDetails = await window.getScreenDetails(); |
There was a problem hiding this comment.
- Is not entirely satisfying to me but I understand it would work mechanically. Having a permission prompt that doesn't actually give the app any new API capabilities, it just makes something you declared in your manifest start working, doesn't feel like a permission to me. It feels like a UI setting. (Again, that's how WCO was designed. We could have made you do a permission prompt to activate WCO but we designed it as a UI setting instead.)
- OK.
- OK.
- I don't think that addresses the question. I asked about what if the user grants the permission (which causes the window UI to disappear) and then wants to get it back again. There's no "evil thing" happening here, it's just a natural thing for a user setting to be reversible. The fact that, upon granting the permission, you will be hiding the entire permission granting UI somewhere else, means it can be tricky for a user to try and undo that change.
These things can probably be sorted out after the explainer lands in the repo, so I won't block the review on it. But I do want to keep talking about what this UI looks like in the non-enterprise non-VDI case. We should have a design in mind that scales beyond a set of trusted partners.
There was a problem hiding this comment.
Thanks for revising! I think the overall changes to use Chrome/OS as an "example" rather than specifically designing for that platform are right what I had in mind.
There are a few comments and changes requested, both on this review and in some inline comments I sent earlier. I'll approve this so we don't need to do another round of reviews, but please address comments.
Cheers
|
I don't have the "power" to merge this btw. Could someone else click the button? |
No description provided.