alert modals should not block browser toolbar
Categories
(Firefox for Android :: Toolbar, enhancement, P3)
Tracking
()
People
(Reporter: topotropic, Unassigned)
References
Details
Attachments
(3 files, 1 obsolete file)
Steps to reproduce
- Go to a site that opens a modal, like https://freddyb.neocities.org/alert-ten-times
Expected behavior
I can still interact with the browser chrome / toolbar and for example go to the tab tray to close the tab
Actual behavior
The browser chrome / toolbar is blocked until I interact with the modal
Device information
- Firefox version:
- Android device model:
- Android OS version:
Any additional information?
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Fenix::Toolbar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•1 year ago
|
||
Zac says fixing the alert modals might be a lot of work because we'll need to implement a new view that covers the page but not the toolbars.
Comment 3•1 year ago
|
||
Firefox screenshot
Comment 4•1 year ago
•
|
||
Chrome screenshot. Chrome's alert modal covers the page without covering its toolbar.
Comment 5•1 year ago
|
||
This started from the same place as bug 1554975 (the reporter of that bug is the "freddyb" of the demo URL in comment 0), but it is not a dupe. In bug 1554975 we implemented a way for users to escape prompt-loop traps, and that was "good enough" as an abuse mitigation in the short-term. But the fundamental problem was what Nicole points out here: these prompts block access to the browser UI (they are "application modal") and you can't do anything else in the app until you deal with it. As Chris's screenshot shows, Chrome treats these as "tab modal". At a first glance they look very similar to ours, but in Chrome you can access the browser toolbar and close an abusive tab, switch to another tab, or access some setting in our menus without having to respond to that prompt. On desktop, Firefox prompts are also tab-modal.
There are some implementation subtleties to think about. What if the browser toolbar is hidden because of scrolling? The user needs to be able to access it so either a) we let the user scroll it back into view or b) we always un-hide the toolbar when there's a prompt. The downside to a) is that users might not figure out they can do that. The downside to b) is that a malicious site would then be able to use an alert() to launch a clickjacking attack on the toolbar. I don't currently see anything worth targeting, but if we ever added anything dangerous in the future we might forget to worry about this. (One possibility: would we ever allow add-on buttons for easy tool access?) My personal preference is behavior b), but we should add the anti-clickjacking delay when we do so for a bit of "better safe than sorry" future-proofing.
Another interesting complication is fullscreen. We don't show any browser UI in that mode—could an alert() trap you in fullscreen? I don't think so. Even app-modal UI doesn't prevent you from accessing and using the OS back button to exit fullscreen, and then getting to the browser toolbar (assuming we fix this bug).
| Comment hidden (obsolete) |
Comment 7•1 year ago
|
||
Description
•