1813213 - Sticky elements at bottom of page have wrong click areas

Status: RESOLVED FIXED

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

Description

[Jonathan Almeida [:jonalmeida]]

From github: https://github.com/mozilla-mobile/fenix/issues/19217.

Steps to reproduce

Open this sandbox.

Expected behavior

Click event should be triggered exactly by clicking element.

Actual behavior

Scroll down a bit and after bottom browser bar hides click any button in sticky container at bottom of the page. Click areas are shifted to top by browser bar height. So red button click triggers by clicking at empty space a bit higher than element displays, same as blue button, that click triggers also at wrong area. With visible browser bar all works as expected.

Device information

• Device vendor / model and Android version: OnePlus 3T, Android 9, OxygenOS 9.0.6
• Firefox for Android version: 88.1.1 (Build #2015804891)

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Comment 1

[Jonathan Almeida [:jonalmeida]]

In one of the comments, there is a nice video that demos the core problem with the toolbar which makes this bug severity easier to gauge: https://github.com/mozilla-mobile/fenix/issues/19217#issuecomment-1007686438

Comment 2

[Chris Peterson [:cpeterson]]

QA, can you reproduce this bug? Mike says he can't reproduce it in Fx 125. He thinks the bug might have been fixed.

Comment 3

[Lorand Janos]

Hi,
I cannot open the sandbox example given in the description, the page appears with a 404 code for a moment and then it's blank.
However it opens on Chrome.
Can a usable example be created to test this issue?
Thank you!

Comment 4

[Lorand Janos]

Attachment: Edited_Recorder_15032024_163610.mp4

Comment 5

[Chris Peterson [:cpeterson]]

I get a 404 error (or blank page) in Chrome or Firefox on Android or Windows. I'll just resolve this bug as incomplete. Thanks for checking!

Comment 6

[Jonathan Almeida [:jonalmeida]]

Attachment: testcase.html

The github issue has a link to the jsfiddle example, so I used the SingleFile addon to extract it out and upload it here.

I can still reproduce this bug in 124 on my Pixel 6a, so re-opening for QA.

Comment 7

[Lorand Janos]

Thank you Jonathan,
I managed to reproduce the described issue using the link given above.
After the address bar is dismissed by scrolling down, the area above the part intended to be clickable is also triggered with the added height of the address bar.
Device used for testing: Samsung Galaxy S23 Ultra (Android 14).
Tested builds: Nightly 126.0a1, Beta 125.0b2 and RC 124.0.

Comment 8

[Chris Peterson [:cpeterson]]

UX Fundamentals bug for squad 3

Comment 9

[Chris Peterson [:cpeterson]]

Setting UX Fundamentals bugs to priority P2 because we want to fix them this year.

Comment 10

[Greg Stoll :gstoll]

I haven't been able to make time for this, nor have I made much progress.

Comment 11

[Christian]

Attachment: Screenshot_mobile_diff.png

I am experiencing this bug, too. The attached screenshot shows the issue and can be reproduced at this URL: https://stollr.github.io/firefox-android-issue/

Browser version: 129.0.2
Device: OnePlus 6
Screen size: 1080 x 2280 px
CSS viewport size: 432 x 912 px

Comment 12

[Markus Stange [:mstange]]

I think this is an APZ issue. When the dynamic toolbars are hidden, it appears that main thread hit testing on sticky elements is behaving incorrectly. Hiro, do you know if we do anything special for position:fixed-to-bottom hit testing that we don't do for position:sticky?

Comment 13

[Hiroyuki Ikezoe (:hiro)]

(In reply to Markus Stange [:mstange] from comment #12)

I think this is an APZ issue. When the dynamic toolbars are hidden, it appears that main thread hit testing on sticky elements is behaving incorrectly. Hiro, do you know if we do anything special for position:fixed-to-bottom hit testing that we don't do for position:sticky?

No, as far as I know of we don't do anything special for position:fixed-to-bottom elements on the main thread with dynamic toolbar interactions in terms of hit-testing. That's because, I guess, position:fixed elements are out-of-flow (I am unsure I am correctly using this out-of-flow term), whereas position:sticky elements are kinda in-flow inside the scroll container.

Comment 14

[[e-mail]]

Hello
Firefox 130
The problem is still reproducible.
I've created a demo when you can see it. The problem is not reproduced on other browsers (Chrome, Opera, Safari).

1. Open Playground https://playcode.io/2017908
2. Open a preview of the page in mobile Firefox.
3. Be sure that auto-hide for the address bar is enabled (... - Settings - Customize - Scroll to hide toolbar)
   PS I could provide a zip file with a demo if needed

Comment 15

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1813213 - Factor the dynamic toolbar bimodal height into position sticky elements stuck to the root scroll container. r?botond

And kick a reflow for the sticky elements when the dynamic toolbar is hidden so that
the sticky elements' position laid out on the main-thread is properly updated there.

These stuffs are basically same as we've done for position:fixed elements.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/67d2c05edf11
Factor the dynamic toolbar bimodal height into position sticky elements stuck to the root scroll container. r=botond,geckoview-reviewers,m_kato

Comment 17

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/67d2c05edf11