1996198 - Guardian: Hit tests on fixed-bottom element are off by URL bar size, when dynamic toolbar is hidden with enabling SHIP

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect, P2)

Description

[Jake Archibald [:jakea]]

Attachment: Demo

On https://www.theguardian.com/politics/live/2025/oct/24/caerphilly-byelection-result-live-reform-plaid-cymru-labour-wales-welsh-government-senedd-latest-voting-news (and similar Guardian pages), I've encountered an issue where elements that are position-fixed to the bottom of the viewport have incorrect hit testing when the URL bar is scrolled away. The hit tests are wrong by the size of the URL bar.

My URL bar is fixed to the bottom, which may be a cause.

I tried to create a reduced test, but everything worked fine. I couldn't figure out the trigger of the issue.

Comment 1

[Jake Archibald [:jakea]]

In case you can't get the popover to appear, I've had some luck with going to the page and running:

const div = document.createElement('div');
Object.assign(div.style, { position: 'fixed', width: '100%', bottom: '0', height: '100px', zIndex: '1000', background: 'red' });
document.body.append(div);

And that sometimes has the same positioning issue. It looks visually in the right place, but if you inspect with devtools you'll see the hit test position is wrong.

It doesn't always happen.

Comment 2

[Jake Archibald [:jakea]]

I've tried hiding/showing a bunch of elements, and sometimes the bug fixes itself until the next reload, but I can't track down the reason.

Comment 3

[Timothy Nikkel (:tnikkel)]

Maybe this sounds like a bug you are already aware of?

Comment 4

[Hiroyuki Ikezoe (:hiro)]

I remember there were a couple of this kind of hit-testing errors on position:fixed element with dynamic toolbar, but I am not sure whether there's still any open bug or not.

Unfortunately on my end I don't see the position:fixed element on the site. And with the appended element by the script in comment 1, I don't see any hit-testing issue on the element. (Note that I did addEventListener("click", () => console.log("click")))

Comment 5

[Hiroyuki Ikezoe (:hiro)]

I found one; bug 1772273

Comment 6

[Jake Archibald [:jakea]]

Attachment: Debugging demo

Here's a test with:

const div = document.createElement('div');
Object.assign(div.style, { position: 'fixed', width: '100%', bottom: '0', height: '100px', zIndex: '1000', background: 'red', pointerEvents: 'auto' });
document.body.append(div);
div.onclick = () => { div.style.background = 'blue'; setTimeout(() => div.style.background = 'red', 100) };
document.body.style.pointerEvents = 'none';

It doesn't always happen, so you need to refresh and try it a couple of times. Note that weirdly, the url bar area is clickable, but above it is also clickable.

Comment 7

[Botond Ballo [:botond]]

(In reply to Timothy Nikkel (:tnikkel) from comment #3)

Maybe this sounds like a bug you are already aware of?

I'm not aware of an existing open bug about this, though we've had similar bugs in the past that have since been fixed.

(I think bug 1772273 is unrelated; based on the diagnosis in bug 1772273 comment 5, I would expect that to affects codepaths related to a transient transform due to async scrolling, but not the dynamic toolbar.)

I've tried to reproduce multiple times using the steps in comment 6 (and in one case I also got the "support" popover shown in the issue description, and tried with that too), but so far I haven't been able to.

Comment 8

[Hiroyuki Ikezoe (:hiro)]

pointer-events makes me suspect bug 1916028.

Comment 9

[Jake Archibald [:jakea]]

Pointer-events isn't needed to reproduce the bug, it's just there in the demo to prevent accidentally clicking links.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

One confusing point here in this bug is that the highlight area that devtools shows doesn't consider position:fixed element position changes by dynamic toolbar. It's independent from hit-testing. Filed bug 1996389 for that.

Comment 11

[Jake Archibald [:jakea]]

Huh, I tried to create a reduced demo, and failed, but there the devrools highlight is in the correct place.

Comment 12

[Jake Archibald [:jakea]]

Attachment: av1.mp4

1. Go to https://random-stuff.jakearchibald.com/
2. Click "firefox-android-position-fixed-hit-test"
3. Scroll the URL bar away
4. Tap above the button

I don't know why, but the page navigation seems to cause the demo to work???

Comment 13

[Botond Ballo [:botond]]

(In reply to Jake Archibald [:jakea] from comment #12)

Created attachment 9522562 [details]
av1.mp4

1. Go to https://random-stuff.jakearchibald.com/
2. Click "firefox-android-position-fixed-hit-test"
3. Scroll the URL bar away
4. Tap above the button

I don't know why, but the page navigation seems to cause the demo to work???

Thanks for your persistence in finding reproduction steps!

I can reproduce the issue with these steps, and we should now be able to debug it further.

Comment 14

[Daniel Holbert [:dholbert]]

I can reproduce with Jake's steps in comment 12 as well. FWIW the most recent bug like this that I recall is bug 1917906 (which has bug 1917733 and bug 1813213 as related bugs). Those ones are all fixed, so likely this is different; just mentioning them (and adding bug 1917906 as see-also) in case the issue/fix might lie in the same area.

Comment 15

[Daniel Holbert [:dholbert]]

Note: if you pinch-zoom Jake's testcase a little bit, then the footer visually detaches from the bottom of the screen when you scroll, so that the button visually shifts away from the edge of the screen by the size (or pinch-zoomed size?) of the dynamic toolbar. Botond says that's likely bug 1880375. Adding that as see-also, since that visual-misplacement seems possibly related to the touch-event-misplacement that we're hitting here.

Comment 16

[Daniel Holbert [:dholbert]]

(I tried to mozregression bisect a little bit, and found 2025-05-19 as a possible last-good build -- at least, it gave me some "good" results - but I was also able to elicit bad-results from it when retesting and navigating back and forth, so I'm not entirely confident. I think I got "bad" builds back to that point, but it's hard to know whether they were truly bad or just unlucky, given my observation with 2025-05-19 being sometimes good and sometimes bad, depending on how I test.)

Comment 17

[Botond Ballo [:botond]]

(In reply to Daniel Holbert [:dholbert] from comment #16)

(I tried to mozregression bisect a little bit, and found 2025-05-19 as a possible last-good build -- at least, it gave me some "good" results - but I was also able to elicit bad-results from it when retesting and navigating back and forth, so I'm not entirely confident. I think I got "bad" builds back to that point, but it's hard to know whether they were truly bad or just unlucky, given my observation with 2025-05-19 being sometimes good and sometimes bad, depending on how I test.)

I played around with this a bit more, and found the following:

• In GVE, the bug seems to go from "intermittently reproducible" in 2025-05-19 to "consistently reproducible" in 2025-05-20. The "intermittently reproducible" state goes as far back as the oldest GVE nightly I'm able to test (2024-10-28, one year ago). [Aside: why are we still only keeping GVE nightlies for one year? I thought we changed that to at least keep nightlies indefinitely...]
• In Fenix, the bug seems to go from "not reproducible at all" in 2025-05-19 to "consistently reproducible" in 2025-05-20.

So I think we can conclude that something regressed between 2025-05-19 and 2025-05-20.

I ran mozregression on that range, with GVE (since that's what we have autoland-granularity builds for), treating "intermittently reproducible" as "good", and found that the regressing bug in that window was bug 1951246 ("Enable SHIP on Firefox Android by default").

Comment 18

[Hiroyuki Ikezoe (:hiro)]

Okay, a problem is here in nsView::DynamicToolbarOffsetChanged. The code is;

   CallOnAllRemoteChildren(
        [aOffset](dom::BrowserParent* aBrowserParent) -> CallState {
          // Skip background tabs.
          if (!aBrowserParent->GetDocShellIsActive()) {
            return CallState::Continue;                                                
          }                                                                            
                                                                  
          aBrowserParent->DynamicToolbarOffsetChanged(aOffset);   
          return CallState::Stop;                     
        });

Looks like the BrowserParent in the BFcache is still active, so we propagate the up-to-date dynamic toolbar height to the previous document.

Comment 19

[Hiroyuki Ikezoe (:hiro)]

Now I confirmed the test case link in comment 12 works on Fenix nightly.

Thank you Jake for the test case, without the test case we would still be struggling to find out what the problem is. :)

Comment 20

[Jake Archibald [:jakea]]

Yay! Thanks so much for fixing this.

Comment 21

[Calin Tanase]

Verified, the issue no longer reproduces. (based on the stepst at 1996198#c12)

Tested with:

• Browser / Version: Fenix 146.0-candidate build 1
• Operating System: Google Pixel 5 (Android 14)