Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mv-ertingen.de - The touch surface of the options from "Browse" menu is misaligned #75903

Closed
webcompat-bot opened this issue Jun 3, 2021 · 5 comments
Labels
browser-firefox-mobile engine-gecko The browser uses the Gecko rendering engine priority-normal severity-critical The site or core functionality is unusable, or you would probably open another browser to use it.
Milestone

Comments

@webcompat-bot
Copy link

webcompat-bot commented Jun 3, 2021

URL: https://mv-ertingen.de/

Browser / Version: Firefox Mobile 90.0
Operating System: Android 10
Tested Another Browser: Yes Chrome

Problem type: Site is not usable
Description: Buttons or links not working
Steps to Reproduce:
When tapping an item in the hamburger menu (on a mobile device), it will often activate the item above the item that was tapped.
So, the touch surface of the items in the hamburger menu is misaligned with their visual representation (by about half the height of an item on my phone).

I've only been able to reproduce this problem in (various versions of) Android Firefox. It works fine on Desktop Firefox and Chromium-based browsers.

The most extraordinary/hacky aspect of that menu's implementation (and therefore possible source for unusual behaviour), is the use of an invisible checkbox to remember the open-state of the menu, because I wanted to achieve responsive design without the use of JavaScript.

View the screenshot Screenshot
Browser Configuration
  • None

From webcompat.com with ❤️

@webcompat-bot webcompat-bot added the action-needsmoderation The moderation has not yet been completed label Jun 3, 2021
@webcompat-bot webcompat-bot added this to the needstriage milestone Jun 3, 2021
@webcompat-bot webcompat-bot added the browser-fixme This requires manual assignment for the browser name label Jun 3, 2021
@webcompat-bot webcompat-bot changed the title In the moderation queue. mv-ertingen.de - site is not usable Jun 4, 2021
@webcompat-bot webcompat-bot added browser-firefox-mobile engine-gecko The browser uses the Gecko rendering engine and removed action-needsmoderation The moderation has not yet been completed browser-fixme This requires manual assignment for the browser name labels Jun 4, 2021
@softvision-oana-arbuzov softvision-oana-arbuzov added priority-normal severity-critical The site or core functionality is unusable, or you would probably open another browser to use it. labels Jun 9, 2021
@softvision-oana-arbuzov softvision-oana-arbuzov changed the title mv-ertingen.de - site is not usable mv-ertingen.de - The touch surface of the options from "Browse" menu is misaligned Jun 9, 2021
@softvision-oana-arbuzov
Copy link
Member

Thanks for the report, I was able to reproduce the issue.
MisalignedTouch

Note: The issue is not reproducible on Chrome.
image

Tested with:
Browser / Version: Firefox Nightly 91.0a1 (🦎 91.0a1-20210607094749)
Operating System: Google Pixel 5 (Android 11) - 1080 x 2340 pixels, 19.5:9 ratio (~432 ppi density)

Moving to Needsdiagnosis for further investigation.

@denschub
Copy link
Member

denschub commented Aug 20, 2021

This site has a couple of interesting quirks, the original reporter was not kidding. :)

The entire menu is implemented without JS, and using some clever state-hacks instead. The submenu points - "Verein", "Jugend", and "Sonstiges" aren't expanded via a onClick handler, but instead, they're just bare <li>s with nested <ul>s inside them. These nested <ul>s have display: none; by default, but they turn visible if the parent <li> has :hover. The menu items without sub-items, "Aktuelles" and "Termine", however, are large <a>s inside the <li>s.

Web developers probably have the assumption that browsers always click on the exact pixel the user touched on, but that's not really true. Especially on touchscreens, user input is fairly imprecise, and browsers try to "make sense of it". For Firefox, this means that we treat the point of touch as a "suggestion", expand that area to 3mm to the left/right, 5mm to the top, and 2mm to the bottom. Inside this area, which is now a 6x7 millimeters wide "touch area", we look for clickable elements, and if there are clickable elements found, we click on the one that is closest to "the finger". This is kinda required on touch screens because fingers are a lot larger than one pixel, and requiring users to pixel-accurately click on a link would probably frustrate them. One can disable this behavior by toggling the pref ui.mouse.radius.enabled to false in about:config, and if we do that, the menu works "as expected".

If we take this site's main menu and remove all irrelevant attributes and all subnavigation-<ul>s - they'll get ignored anyway because they're hidden - the menu's markup looks like this:

<ul>
  <li><a href="/">Aktuelles</a></li>
  <li><span>Verein</span></li>
  <li><span>Jugend</span></li>
  <li><a href="https://www.mv-ertingen.de/termine/range.listevents/-">Termine</a></li>
  <li><span>Sonstiges</span></li>
</ul>

Earlier, I mentioned that we prefer things that are clickable, and you might immediately notice the issue now: nothing about a <span> inside a <li> is "clickable". From Firefox point of view, here is what happens in a simplified fashion. I clicked on "Verein", and I'll simplifiy the actual log output to make it understandable and I've left out several node-checks for brevity:

  1. Found initial target [text "Verein"] for event class eMouseEventClass message eMouseDown point (4050,12390)
  2. Expanded point to target rect (x=2916, y=10500, w=2268, h=2646)
  3. Checking candidate [text "Verein"] with border box (x=1440, y=11927, w=3425, h=1110)
    candidate [text "Verein"] was not clickable
  4. Checking candidate [the <span> around the text] with border box (x=0, y=11162, w=21600, h=2640)
    candidate [the <span> around the text] was not clickable
  5. Checking candidate [the <li> containing "Verein"] with border box (x=0, y=11162, w=21600, h=2640)
    candidate [the <li> containing "Verein"] had empty hit region
  6. Checking candidate [the <a> containing "Aktuelles"] with border box (x=0, y=8522, w=21600, h=2640)
    candidate [the <a> containing "Aktuelles"] is the new best
  7. [Firefox continues checking other elements that are within the finger-radius but all not clickable]
  8. Final target is [the <a> containing "Aktuelles"]

To see the actual log, you can run Firefox with MOZ_LOG=event.retarget:4. But unfortunately, to understand what's going on, you need to resolve the pointers the log is showing you, and you kinda need a debug build for that. For reference, I've attached the full log output and a frame dump to make the log output understandable.

So, what's happening here is that Firefox knows I clicked on "Verein", but then it goes on expanding the "click region" as described earlier, and unfortunately, there's a very real and very clickable link within that region. And from Firefox' point of view, assuming that the user meant to click on "Aktuelles" makes sense, because nothing else below the user's finger is clickable.

There is a bit of hidden logic in what Firefox actually considers "clickable", and this is worth knowing in this case. Here is Gecko's actual implementation of the time of writing this, but I won't make you read C++ code. Here's what is "clickable":

  • <a>s.
  • <button>, <input>, <select>, <textarea>, <label>, and <iframe>.
  • Elements with JS listeners for:
    • click, mousedown, mouseup
    • touchstart, touchend
    • pointerdown, pointerup
  • Elements with contenteditable="true".
  • Elements with role="button".
  • Elements with cursor: pointer assigned via CSS.

So it's quite a lot of things. Satisfying any of the conditions at the elements with submenu items would make it "work as expected". For example, setting the pointer cursor for the spans with

#topmenu span {
  cursor: pointer;
}

will make it work just fine. From an accessibility point of view, they should add role="button" to the <span>, which also makes it work. I'll reach out to the site and let them know, but given they're using a Joomla template last updated in 2013, I have little hope.

One possible Gecko change could be to treat elements with mouseover handlers or :hover styles as valid targets. I can think of a couple of reasons why that's a good idea, but I also can think of reasons why that's horrible. I filed a bug for that so that people with more experience in this stuff can make that decision.


... this probably should be a blog post. :) Edit: It is.

@denschub denschub removed their assignment Aug 20, 2021
@denschub denschub modified the milestones: needsdiagnosis, sitewait Aug 20, 2021
@mv-ertingen
Copy link

Hi, reporter of the WebCompat ticket here.
Thanks for the in-depth analysis and blog post. It was really fun to read. :)

And I do also happen to be the administrator and (hobbyist) webdev of mv-ertingen.de, so I did fix the issue on the webpage just now, as per the suggestion of adding role="button" to the <span> tags.
(Yes, the original template isn't being updated anymore, but I've basically forked it to make tweaks here and there.)

So, it does work now on Firefox For Android, and with a separate issue filed to investigate whether it's worth tweaking the Firefox behaviour, I think this issue can be closed now.

Thanks again and cheers!

@denschub
Copy link
Member

That's absolutely amazing to hear! :) Thanks for getting back to us.

I'll close this issue as fixed.

@denschub denschub modified the milestones: sitewait, fixed Aug 24, 2021
@softvision-oana-arbuzov
Copy link
Member

Thanks @mv-ertingen , I can confirm it is working now.
image

Tested with:
Browser / Version: Firefox Nightly 93.0a1 (🦎 93.0a1-20210823092315)
Operating System: Google Pixel 5 (Android 11) - 1080 x 2340 pixels, 19.5:9 ratio (~432 ppi density), Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
browser-firefox-mobile engine-gecko The browser uses the Gecko rendering engine priority-normal severity-critical The site or core functionality is unusable, or you would probably open another browser to use it.
Projects
None yet
Development

No branches or pull requests

4 participants