1753019 - Mozilla Android AddressBar Conflict with Sticky Button on Bottom

Status: RESOLVED FIXED

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

Description

[johnaps94]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36

Steps to reproduce:

I have created a button that is after the content and have applied css for it to become sticky at the bottom of the page...

<button class="ocs-trigger ocs-toggle ocs-toggle-posts-toc-mobile">Περιεχόμενα</button>
button.ocs-toggle-posts-toc-mobile {
display: block;
bottom: 10px;
position: sticky;
position: -webkit-sticky;
margin: auto;
border-radius: 4px;
box-shadow: 0 0 3px 0 #d5d5d5;
background: #232f3e;
font-weight: 500;
font-size: 18px;
padding: 7px 12px;
}
It works everywhere in any browser i tested except mozilla android. If mozilla bottom adressbar is visible the button works okay. https://imgur.com/a/EJosALR

BUT if mozilla’s bottom address bar is hidden, the button isnt clickable. https://imgur.com/a/A2jwzIl

See the faulty behavior on action: https://i.stack.imgur.com/LAHor.gif

test url: https://thefinterest.kinsta.cloud/p/asjalska/

Also there is an active thread in Stackoverflow about this:
https://stackoverflow.com/questions/70893056/mozilla-android-addressbar-conflict-with-sticky-button-on-bottom

Actual results:

The button isnt clickable because it actual position get wrongly calculated...

Expected results:

The sticky element should be clickable despite if the mozilla adressbar is visible or hidden!

Comment 1

[Hiroyuki Ikezoe (:hiro)]

We actually fixed position:sticky case in bug 1594451, but probably I've missed some cases.

Comment 2

[johnaps94]

It would be perfect if this case could also be fixed, or if you have some suggestion to "bypass" this problem on firefox!

Comment 3

[Botond Ballo [:botond]]

I expect this code needs to be adjusted to handle position:sticky.

Bug 1594451 fixed the rendering codepath for position:sticky elements (to have their position follow the dynamic toolbar), as well as another codepath (which, now that we use WebRender, is only used for scenarios related to scrollbar dragging), but it's still necessary to adjust the above codepath for correct targeting of touch input events. (Sorry for overlooking this during the review of bug 1594451.)

I'm going to tentatively mark this as S2 as this bug can manifest in the user not being able to click a button important for a site's operation, and the workaround (of scrolling up to show the toolbar and then clicking again) may not be obvious.

Comment 4

[Dan Robertson (:dlrobertson)]

Attachment: Bug 1753019 - Use the animation id to identify hit testing metadata. r=botond,tnikkel

Comment 5

[Dan Robertson (:dlrobertson)]

Attachment: Bug 1753019 - Adjust sticky position elements for the dynamic toolbar. r=botond,tnikkel

Depends on D148648

Comment 6

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/1866a8784a87
https://hg.mozilla.org/mozilla-central/rev/dbc151128737