1923836 - URL bar drop-down renders behind notification bars

Status: NEW

(Firefox :: Sidebar, defect)

Description

[Jonathan Kew [:jfkthame]]

Attachment: Screenshot 2024-10-10 11-20-49.png

(I'm not sure which component this should belong to... filing as General for triage.)

The attached screenshot is from my newly-built Nightly on Ubuntu 24.04. When first launched, it shows a notification bar "Some of Nightly's security features may offer less protection....". Without dismissing that notification, I started typing into the URL bar, and saw that -- rather disconcertingly -- the URL bar dropdown rendered behind the notification bar. That seems unexpected/wrong.

(Since the screenshot, a second notification bar -- "You have 5 unsent crash reports" -- has also appeared, and now the URL bar dropdown renders behind both of these. So the issue seems to be with notifications in general, rather than one specific message.)

Comment 1

[Francesco Lodolo [:flod]]

What's the changeset used by the build?

We had some issues (bug 1922802) that should be fixed today, I would expect this to be a manifestation of the same bug.

EDIT: on the other hand, that bug was happening with Vertical tabs enabled, and that's not the case in your screenshot.

Comment 2

[Jonathan Kew [:jfkthame]]

This build is 541f36a6b102, which is currently the most recent mozilla-central changeset.

Comment 3

[Francesco Lodolo [:flod]]

My Nightly is still on 20241009214609, but I can confirm the behavior on a Nightly built from mozilla-central on macOS, and with the pop-up blocked notification.

Comment 4

[Francesco Lodolo [:flod]]

INFO: Last good revision: 3ba1f9c5546437d60d168b63681506f8b8120e2d
INFO: First bad revision: ba57d03292b60f241cd1d9a50b9e0f4a63d91aed
INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3ba1f9c5546437d60d168b63681506f8b8120e2d&tochange=ba57d03292b60f241cd1d9a50b9e0f4a63d91aed

Comment 5

[Erwan]

Same, I rediscovered it after re-opening Firefox Nightly Version 133.0a1, build ID 20241009214609.

Comment 6

[Erwan]

Corrected now with receipt of the update:
Firefox nightly Version 133.0a1 Build ID 20241010092233

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Erwan from comment #6)

Corrected now with receipt of the update:

Just removing ambiguity here - this bug (the info-bar painting on top of address-bar-dropdown) is not corrected yet. Latest Nightly (build ID 20241010092233) still reproduces the bug, for me at least.

(If I'm understanding correctly, I think comment 6's "corrected now" was Erwan correcting their previous comment, where they had posted a different build ID. Or if I'm misunderstanding Erwan and the bug somehow did correct itself for them, that's interesting and might be worth looking into RE under-what-conditions it reproduces vs. does-not-reproduce.)

Comment 8

[Daniel Holbert [:dholbert]]

(Or perhaps Erwan was meaning to post on bug 1922802 about that bug being corrected.)

Comment 9

[Francesco Lodolo [:flod]]

This is now in official Nightlies (20241010092233). I'm going to mark the last comments as off-topic to make the conversation easier to follow.

Comment 10

[Daniel Holbert [:dholbert]]

Diagnostic / what's-going-on-here notes:

The regressing bug bug 1922802 gave #nav-bar a z-index of 1 (technically z-index: var(--browser-area-z-index-toolbox);, where the variable there evaluates to 1). Previously it had a z-index of auto.

That change forces #nav-bar to form its own stacking context, per second bullet-point of https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_positioned_layout/Understanding_z-index/Stacking_context ("A stacking context is formed...by...: Element with a position value ... relative and z-index value other than auto.")

And if it forms a stacking context, then it encapsulates its absolutely-positioned child (#urlbar[breakout], the address bar dropdown-menu) to paint atomically as part of #nav-bar, regardless that absolutely-positioned child's own stacking-order-preference (which is more-in-the-foreground due to it having its own z-index: 3 styling, which now is just interpreted relative-to-other-stuff-inside-of-#nav-bar).

This ends up meaning that it paints behind the info-bar here, because the info-bar comes later in the DOM than #nav-bar and also has z-index:1.

We could hypothetically paper over this by giving #nav-bar z-index: 2 instead (so that it and its abspos dropdown-menu would stack in front of any z-index:1 siblings), but I'm not sure offhand if this would end up having other bad side-effects.

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase to demonstrate the effect of adding "z-index:1" to nav-bar in this case

If it helps to reason about the explanation in comment 10, here's a reduced demo of the nav-bar/url-bar-dropdown/info-bar, comparing before vs. after we added z-index to the nav-bar. (In the bottom half of this testcase, with "z-index:1" added to the nav-bar, the abspos url-bar-dropdown gets covered up by the info-bar, just as in the actual Firefox frontend code.)

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing that this affects the vertical-tabs config as well

Given that the regressor was fixing a verticalTabs-specific bug, it occurred to me to test whether or not this affects the verticalTabs scenario as well. It does; here's a screenshot.

Comment 13

[Nikki Sharpley (:nikkis) (she/her)]

I think this should be resolved one Bug 1921811 fix lands. This aims to make the address bar dropdown a popover so it appears over all content.

Comment 14

[Sam Foster [:sfoster] (he/him)]

We have a whole series of bugs which are fallout and related to z-index and the work happening around vertical tabs. If more come in, please forward them along to the Sidebar component so we can spot dupes, and coordinate how and when we fix this stuff. Like :nikkis said, we're working on the issue bug 1921811, but we'll need to triage to see if we can wait for that to land or if a backout or shorter-term response is needed.