It's not totally clear to me a) exactly what attacks this will mitigate, or b) how we'd implement it. It may not be worth doing if we don't have concrete attacks in mind. But a worthwhile thing to consider.

Yah. We often refer to those surfaces as secondary UI (dialog, infobar, bubble, alert, etc.), to distinguish them from "top chrome" (tabs, toolbar, titlebar). 

Caveat: I tossed this out as a possible path, but I haven't thought deeply about it yet. So maybe this bug could be for doing some more due diligence? 

+hwi, +emilschechter 

Due diligence is great!

I'm confused about how this would mitigate the attack where an alert covers the fullscreen bubble. Wouldn't the fullscreen bubble still be covered?

Yeah, that's why I'm not sure this is that helpful. It might be helpful in other situations though, I just can't see a clear attack where this would help. Or are you suggesting this less as a security thing and more for just consistency of how those bubbles are presented?

I think we could still just fully exit fullscreen as soon as we get an alert.

One thing to consider is whether all dialogs that ask security questions properly display the origin. I'm aware of at least one such dialog that doesn't display the origin: extension inline install (its usage in fullscreen to be restricted by  https://crbug.com/488143 ). For such dialogs, it's not possible to identify which origin is making the request while in fullscreen and showing the browser chrome would help fix that.

re: #3 
The fullscreen toast (esc-education) would not be covered, because the tabs and toolbar are tall enough that secondary (aligned to the bottom edge of the omnibox) would appear beneath it - or with very few pixels of overlap). 

Well alerts also overlap the browser chrome so it would still almost entirely overlap the fullscreen toast. (You can see what the fullscreen toast would look like when not actually in fullscreen mode by using pointer lock: see https://permission.site).

I was thinking of the Mac positioning - we have very little overlap (attached) with tab-modal dialogs there. But generally, showing two messages from chrome at the same time is sad (especially if they overlap) :/ 

Deleted: toast-vs-tab-modal-position-by-os.png 253 KB

	toast-vs-tab-modal-position-by-os.png 253 KB View Download

Ah OK. So we probably should move alerts down into the content area anyway (to make it look like it's part of the content and not a browser-level message).

Errr. It's complicated. avi@ et al have been thinking about that space. When thinking about secondary UI it's also important to consider permissions/FOIL/print/translate/password-save etc. 

Hey Emily, Alex: Raymes suggested we just exit out of fullscreen when there's a modal dialog. Is there any legitimate reason to show a modal dialogue in HTML fullscreen? Otherwise, let's just do this.

+hwi@ is thinking about dialog (and modality) UX so might have ideas 

re: c12, 

- "all popups/secondary UIs" include infobars and anchored dialogs(infobubbles) as well as modal(centered) dialogs. (#c2)
- a reason to show popups in fullscreen is to maintain the immersive nature of fullscreen mode while communicating where a popup is originated from. e.g. keep fullscreen while bookmark anchored dialog is shown (via ctrl/cmd + d)
- a desired top-chrome behavior is something like how OSX fullscreen(the 3rd green circle on the top left of a window) shows top-chrome when mouse touches the top edge of the screen.

I'm not suggesting all popups, but specifically site-triggered modal dialogs (alerts and prompts).

We are trying to get rid of these because they are mostly used for phishing, and we can't think of a legitimate reason why a site would want to use these in combination with fullscreen. Note I'm talking about site-triggered fullscreen, not user-triggered (F11).

So the proposal would be: If the site is in site-triggered fullscreen mode AND an alert dialog is shown, exit fullscreen.

I would put in UMA data collection to see how often this situation arises before we make the final decision.

UMA sounds good.

Q: regarding "site triggered fullscreen", if the user clicks on a button to go fullscreen, e.g. "Present" from Google Slide, is it technically "site triggered" or "user triggered"? 

#16: That would be "site triggered".

User-triggered means they used browser UI to trigger it. Site-triggered means the requestFullscreen API was used (which could be from a user action in site).

Thanks mgiuca@. 

I don't have a real example for c#15: site triggered fullscreen + jsdialogs. 

In my imagination, there might be cases where jsdialogs (like attached screenshots) are used to provide information or notify the user in an api-triggered fullscreen. e.g. fullscreen game > the user is about to quit > JSdialog might be used "are you sure you want to quit?"

So I'm a bit hesitant on the propose "exit fullscreen" behavior.

Also, I still think a solution should be for all popups cases.

Deleted: 01.png 75.0 KB

	01.png 75.0 KB View Download

Deleted: 02.png 55.6 KB

	02.png 55.6 KB View Download

Deleted: 03.png 236 KB

	03.png 236 KB View Download

#18: But we are trying to get away from modal dialogs entirely. We don't want web developers putting in modal dialogs to prompt when the user is quitting; they should build their own prompt in HTML. I think exiting fullscreen is a reasonable intervention here (not actually breaking any functionality).

> Also, I still think a solution should be for all popups cases.

I don't have time to work on all the different types of popups. I don't technically have any time to work on this at all but I'm willing to do alerts because we have the overlapping issue. Let's not let the perfect be the enemy of the good.

+1 to Comment #19. This is something that I think the security team would like to fix and that seems like a feasible way forward given all the constraints.

- #19 and #20: Thanks for the context. I don't see major usability issue of the proposed change. I leave it to you and emilyschechter@ for security needs/usefulness.

- Side suggestion: either splitting a new bug or updating this bug to reflect the scope of the change will be helpful for future visit to the bug.

Thanks!

Decided not to do this fix, in favour of  Issue 670135 .