1936615 - Allow <select> menu-popups to overflow off the bottom of the content area (in the direction away from the location bar)

Status: REOPENED

(Core :: Layout: Form Controls, defect, P3)

Description

[stephen.cunliffe]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

Any <select> list dropdown is now cropped/restricted to the browser window viewport, vs. overhanging it.

Actual results:

Any <select> list dropdown is now cropped/restricted to the browser window viewport. (This was noted in Windows 10, Latest Firefox (133), may or may not affect other versions/OSes)

Expected results:

Any <select> list dropdown should extend beyond the browser window viewport if needed (while remaining within the OS screen visible area)

Attaching test case after bug report creation

Comment 1

[stephen.cunliffe]

Attachment: Minimum repro test case

Attaching repro test case.

View in Chrome/Chromium, or other older Firefox browsers to see the regression

Comment 2

[stephen.cunliffe]

Attachment: Firefox Cropped select list

Firefox, cropped select list

Comment 3

[stephen.cunliffe]

Attachment: Chrome un-cropped select list

Chrome uncropped select list

Comment 4

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 5

[stephen.cunliffe]

Issue appears in MacOS Firefox too.

Comment 6

[stephen.cunliffe]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #4)

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Since this is happening in MacOS too, I think it doesn't belong in Win32.

Comment 7

[Ray Kraesig [:rkraesig]]

(In reply to stephen.cunliffe from comment #6)

Since this is happening in MacOS too, I think it doesn't belong in Win32.

Thanks for confirming! Forwarding to Core :: DOM & HTML, which is at least probably close enough to make it to the right area.

I can repro locally... but I can also repro in ESR 115. :/ Since you've indicated that this is a regression for you, can you try running mozregression to determine exactly when it started?

Comment 8

[stephen.cunliffe]

That mozregression tool is amazing! huge props to everyone that worked on that tool, super cool, all apps should have this!

ok, so it turns out this regression bug goes waaaaay back! 2016 baby!

Works fine in this build:
app_name: firefox
build_date: 2016-06-09
build_file: C:\Users\cunlic.mozilla\mozregression\persist\2016-06-09--mozilla-central--firefox-50.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2016/06/2016-06-09-13-06-07-mozilla-central/firefox-50.0a1.en-US.win64.zip
changeset: 3ccccf8e5036179a3178437cabc154b5e04b333d
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3ccccf8e5036179a3178437cabc154b5e04b333d&tochange=016e0f47e8ad66ba6eb11fe28958e3a69ef9e53d
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

but fails in this build the next day:
app_name: firefox
build_date: 2016-06-10
build_file: C:\Users\cunlic.mozilla\mozregression\persist\2016-06-10--mozilla-central--firefox-50.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2016/06/2016-06-10-07-36-07-mozilla-central/firefox-50.0a1.en-US.win64.zip
changeset: b6f7d0eb61b1878d3d906bd231edf225463ece3f
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3ccccf8e5036179a3178437cabc154b5e04b333d&tochange=b6f7d0eb61b1878d3d906bd231edf225463ece3f
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

If I understand the tool correctly ?, the breaking change should be in this changeset

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3ccccf8e5036179a3178437cabc154b5e04b333d&tochange=b6f7d0eb61b1878d3d906bd231edf225463ece3f

I don't know the codebase well, nothing in the commits I could see jumped out as being obvious, but this commit talked about "dealing with overflow containers" as such is my best guess at where the change was:
https://hg.mozilla.org/mozilla-central/rev/913b86ac15a73ab7132279835e0ab764989a07f9

Hope this helps!

Comment 9

[stephen.cunliffe]

Attachment: Mozregression results

Comment 10

[Daniel Holbert [:dholbert]]

In that range, the relevant bug is bug 1276976.

Comment 11

[Daniel Holbert [:dholbert]]

(and the described results here are essentially the intended outcome of that bug's patch, I think; it's cosmetically not great but it's important from a security perspective, as discussed over there)

Comment 12

[Daniel Holbert [:dholbert]]

Essentially the principle here is that the <select> menu-popup's content is controlled by an untrusted web page -- so out of an abundance of caution, it's best to constrain it to the rendering area of the web page. Otherwise, attackers can craft sneaky attacks that use a <select> to cover up a piece of the browser UI and confuse the user, with potentially security-critical results.

The attack scenario in bug 1276976 involved a web page with a <select> that was crafted to pop upwards and cover up Firefox's URLbar, with the <select> menu containing a menu-option that might confuse a user into thinking it's an actual website URL -- e.g. let's say it has a menu-option whose text is 🔒 https://bankofamerica.com, which exactly covers up the area where the browser's URL bar would normally be.

With that sort of setup, and with a spoofed web page that looks convincingly like the actual Bank of America front-page with a username/password field, an attacker could potentially convince some users that they really were looking at their bank's website and they might feel safe entering their username and password. The user would have to click the select button in order to trigger the attack, so it requires some additional effort on the part of the attacker. But in any case: select-popups-that-potentially-escape-the-content-area-and-cover-up-browser-UI give the attacker a very important tool that they can use to build an attack like this.

Given all that, I think this is WONTFIX since this is in fact things working-as-intended per bug 1276976.

Comment 13

[stephen.cunliffe]

I'm not sure how this got intertwined with other domains... my apologies if the changelog item I linked to is the WRONG one.

This issue is a usability issue, and has NOTHING to do with any other domains, or the URL bar.

This is exclusively to do with the <select> list element within a given web site/app page.

I realize that popup windows for example, are not highly desired, however they are still HEAVILY used in large enterprise applications, making the <select> lists very hard to use in FIREFOX only.

Please reconsider opening this, I feel super strongly that this bug needs to be addressed.

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to stephen.cunliffe from comment #13)

This issue is a usability issue, and has NOTHING to do with any other domains, or the URL bar.

This is exclusively to do with the <select> list element within a given web site/app page.

The point of comment 12 (and bug 1276976) is that an attacker can abuse a <select> element to force its menu-popup to cover up the URL bar and confuse users into thinking they're visiting a different site (which they can then use to try to trick the user into typing in their username/password).

For now, our mitigation for that is to constrain <select> popup menus to force them to fit inside the web page's content area, so that it's impossible for them to overlap the location bar. That is indeed a usability tradeoff but it's one that we've decided to make, for the sake of security.

Comment 15

[Ray Kraesig [:rkraesig]]

Would it be feasible to allow <select> popups to extend only below the window, never above it?

(I'm not sure about sideways, which is possible with vertical scripts; and I think mobile can have the URL-bar at the bottom sometimes, so it wouldn't quite be that simple...)

Comment 16

[stephen.cunliffe]

This is "cutting off your nose to spite your face" situation.

I don't agree with this solution (or to be honest, the actual problem) at all.

I will however concede, that if the feeling is that any dropdown overlay, that actually extends up, over the URL bar is something we want to address, then fine, IF the dropdown is actually extending upwards instead of the 99.99% of the time that it extends downward, then go ahead and clip it to the viewport.

However if the drop down, is extending down... like it does 99.99% of the time, then there is NO REASON to restrict the rendering of it to the viewport.

e.g. I'm totally fine with a restriction (if so desired) that says no viewport content, can render over top of the browser navigation/menu/bookmarks 'chrome' (UI, not the vendor), but I think blocking it from rendering outside the viewport on the bottom/right hand sides is not helpful to anyone, and just further blocks Firefox use and adoption full stop.

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to stephen.cunliffe from comment #16)

This is "cutting off your nose to spite your face" situation.

I agree the cost/benefit here is somewhat debatable.

I don't agree with this solution (or to be honest, the actual problem) at all.

So, the original problem looked pretty-bad -- it looks like the original attack here was in bug 868327 and there's a YouTube video showing the attack (spoofing google.fr in the URL bar):
https://www.youtube.com/watch?v=tF5LTfQhSzw#t=0m42s

I think that required the ability to show images in select menus which isn't possible at this point, so making a convincing attack is maybe a bit less tractable at this point. (In that bug, it looks like the patch that landed may have allowed it to open downwards even though it doesn't fit, as you suggest; and we later restricted that in bug 1276976, as part of reimplementing select menu-popups during the "e10s" process-separation effort.)

I will however concede, that if the feeling is that any dropdown overlay, that actually extends up, over the URL bar is something we want to address, then fine, IF the dropdown is actually extending upwards instead of the 99.99% of the time that it extends downward, then go ahead and clip it to the viewport.

However if the drop down, is extending down... like it does 99.99% of the time, then there is NO REASON to restrict the rendering of it to the viewport.

That's a fair request. It looks like bug 1276976 comment 2 is where we came up with the current simple approach. I think there are still valid security concerns with allowing content to draw outside of the content area in general (e.g. there might be some way to leverage that to trick a user into doing something bad), but it's probably a bit of a stretch for select-with-its-limitations to be a workable way for an attacker to do that.

Let's reopen and narrow this in on the feature-request of letting select menus overflow off the bottom of the content area.

(One consideration here is what happens for iframes; I think right now, select menus are constrained to the iframe's bounds, but presumably a robust fix here would relax that restriction too, allowing an iframe to indirectly draw beyond its bounds [via a select menu-popup] in this one particular case).

Comment 18

[Emilio Cobos Álvarez [:emilio]]

This is relatively easy to do. We should change this API to specify edges (or only the top edge perhaps) rather than a full rect.

On mobile this attack doesn't apply because select uses native modal menus, not XUL menus.

Comment 19

[Emilio Cobos Álvarez [:emilio]]

Of course forgot the link: https://searchfox.org/mozilla-central/rev/d1e731d931b7b46237175de1701849a7cf5c8579/toolkit/content/widgets/browser-custom-element.js#1146

The relevant native code would be nsMenuPopupFrame

Comment 20

[Daniel Holbert [:dholbert]]

(In reply to Ray Kraesig [:rkraesig] from comment #15)

I think mobile can have the URL-bar at the bottom sometimes, so it wouldn't quite be that simple...)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #18

On mobile this attack doesn't apply because select uses native modal menus, not XUL menus.

(In particular, from a UX perspective -- on Android, if you tap a <select> button, you don't get a "dropdown"-style UI -- instead you get a modal overlay popup-dialog that floats on top of everything and potentially covers up most of the screen, and that already includes the url bar).

Comment 21

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1276976

:enndeakin, since you are the author of the regressor, bug 1276976, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 23

[stephen.cunliffe]

I'm confused by the status of this bug. I see it is "Open" but I also see that there were 'wontfix' flags set on releases 133 through 135.

Does this mean there is intentions to fix this, its just that the fix version is still not known?

Comment 24

[Daniel Holbert [:dholbert]]

No one is actively working on fixing this, but we might at some point, and we would accept a patch.

Version-specific "wontfix" flags are specific to the indicated Firefox version. In this case those flags were set because our tracking bot flagged a few versions as affected by the bug soon after this was filed, and I adjusted those flags from "affected" to "wontfix" for those versions, because it was clear that we weren't going to fix it in time for releasing those versions (to avoid tripping certain nag rules that the bot might otherwise come back with).