1555446 - Element's "hit boxes" are lower on-screen than they ought to be (due to dynamic nav bar?)

Status: RESOLVED INCOMPLETE

(GeckoView :: General, defect, P2)

Description

[Thomas Wisniewski [:twisniewski]]

There have been two recent issues reported on webcompat.com against Fenix which have strange symtoms:

• https://webcompat.com/issues/31322
• https://webcompat.com/issues/31526

In both cases, when I inspect the elements that the user "cannot tap", I see the remote devtools highlighting areas under the actual on-screen elements, as though the browser believes they are beneath where they really appear. Sure enough, the elements respond to taps in that offset hit-box, rather than on the "real" element.

However, this is not reproducing for me in my Fenix build: 1.0.1922 Build# 11490610
It is only reproducing for me in my Reference Browser build: 1.0.1922 Build# 11491211

To me this implies that this is a bug that is somehow newer than my Fenix version, implying that it may be a regression.

Comment 1

[Chris Peterson [:cpeterson]]

This bug sounds like yet another viewport problem caused by the dynamic bottom address bar. Fenix temporarily disabled the dynamic address bar for Fenix MVP because of these bugs, but Reference Browser still has a dynamic address bar.

Note that Fenix MVP is using GV 68 (now in Beta) and Reference Browser will always use GV Nightly (now 69).

Comment 2

[Chris Peterson [:cpeterson]]

Do Fenix and R-B need to translate the touch event coordinates to account for the toolbar height?

This is not a Fenix MVP blocker because Fenix is not affected when using the fixed-position address bar.

Comment 3

[Chris Peterson [:cpeterson]]

Deferring this bug from Fenix's M7 (July) milestone to the M8 backlog for later in Q3.

Comment 4

[Chris Peterson [:cpeterson]]

I'm editing a bunch of GeckoView bugs. If you'd like to filter all this bugmail, search and destroy emails containing this UUID:

e88a5094-0fc0-4b7c-b7c5-aef00a11dbc9