As long as the fullscreen exit bubble is transient, it seems OK for it to be topmost.

Yes, exactly. It's transient.

We never do that thing anymore where, when you're on a site you haven't been on, the bubble sticks around until explicitly dismissed, do we?  Because that + JS alert underneath would be lame.

I don't know, @hwi do you know?

> We never do that thing anymore where, when you're on a site you haven't been
> on, the bubble sticks around until explicitly dismissed, do we?

No, we don't do that anymore.

It sounds ludicrous, but this really hard:
https://bugs.chromium.org/p/chromium/issues/detail?id=550017#c59

I've been trying to solve this bug, on and off, for about a year. The problem is with the Views system -- it doesn't have any client-settable z-order. It just stacks things in the order they were created. You can override the z-order of something after creating it, but you can't create a window with a z-order higher than a future window that gets created later (all new windows will be on top when they are created).

In this case (unlike the other one I had to deal with regarding permission prompts; https://bugs.chromium.org/p/chromium/issues/detail?id=623862) at least we do know the order in which the dialogs are created: the modal dialog is always created *after* entering fullscreen. Which means at least in theory upon creation of the modal dialog, it could reach into the browser and see whether there is a fullscreen dialog, and set itself to stack behind that one. I discussed this with avi@ and I think the decision was "since we're getting rid of alerts, let's just do that". If we aren't going to do that, then maybe we can have another go at the stacking.

avi@ are you able to do this?

I'm not a Views person, so I can't help with this.

I don't know Views, so I'm not going to be much help here. :(

Looks like I will have to take it.

I'm pretty busy right now but I will try to do this.

There are two approaches:
1. Add code in alert() to find the fullscreen bubble and position the alert() behind fullscreen. Or,
2. Try to make Views/Widgets properly respect z-order. (From memory, there is some kind of always_on_top flag but it doesn't work.)

I guess #2 would help avoid adding more hacks, but I don't know how feasible it is. I'll try and see if it looks feasible.

I was about to say "add an always_on_top flag", so if there's one already, making it actually work seems like a good thing.

I wonder if it's platform-dependent.  Maybe it just maybe to the underlying WM implementation of Always On Top, so it depends on your OS/WM.

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