1726786 - Consider adding hover'able elements as valid targets for event retargeting

Status: NEW

(Core :: Layout, enhancement)

Description

[Dennis Schubert [:denschub]]

In a recent WebCompat bug, we discovered an issue related to the event retargeting with ui.mouse.radius.enabled == true. Full details, including retargeting logs and a frame dump, are available in the linked WebCompat bug.

The site in question implemented a CSS-only multi-level navigation, with the markup resembling something like

<ul>
  <li><a href="/">One</a></li>
  <li>
    <span>Two</span>
    <ul><!-- submenu <li>s --></ul>
  </li>
  <li><a href="/">Three</a></li>
</ul>

The nested <ul>s were display: hidden; by default, but they're set visible if the parent li has :hover. Unfortunately, neither the <li> nor the <span> had any indication that it was clickable - no pointer cursor, no role="button", ... - and in this case, this causes the menu to be hard to use on Firefox for Android. Trying to expand the "Two" submenu pretty much always results in "One" being clicked instead.

Unfortunately, I assume that neither this implementation, nor the lack of "clickable" indication, are all too rare, and this might have a relatively high number of slight-annoyances issues attached to it.

One possible idea is to add elements with mouseover handlers and elements with :hover/:focus styling to the list of good targets for event re-targeting. This would make this site usable, and probably also resolve a couple of other issues. However, I also assume that this has some downsides attached, so I'd appreciate the feedback of someone with more knowledge here. :)

---

(Searchfox told me to file in Core :: Layout for layout/base/PositionedEventTargeting.cpp, but this might just as well be something for Core :: DOM: Events, not sure.)

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Attachment: A simplified case picked from Dennis' blog post

It's working on my Pixel 3. Am I missing something?

Comment 2

[Kartikaya Gupta (email:[e-mail])]

The problem with mouseover is that it's too common; often pages set mouseover listeners on everything and so that would basically defeat the whole fuzzy retageting logic. Using :hover is not an unreasonable suggestion and I considered it before but shelved it in https://bugzilla.mozilla.org/show_bug.cgi?id=1192558#c4 because that scenario got handled by cursor:pointer. The main downside now of checking for :hover is performance (see linked bug comment).

Comment 3

[Dennis Schubert [:denschub]]

Attachment: A simplified case picked from Dennis' blog post

Thanks for your initial feedback!

@Hiro: Not really, that's just a bit misleading from my blog post because the CSS shown is only the bare minimum to illustrate the function. If the a doesn't have display: block;, then it's only as wide as the text itself, so causing overlap is much harder. You'd have to touch precisely below the "One", not to the right of it. I updated your testcase to include display: block on the a and span, and with that, you should see the issue. :)

@Kats: Ah, I somehow did not find bug 1192558 when researching. You're right, this is more or less a duplicate.

I opened this bug mainly to start a small discussion about this, as Chrome and Safari appear to do no retargeting at all, and we've been seeing quite a few issues with retargeting in the recent years (I remember a couple of Covid-Dashboards with lots of issues in Fenix - but back then I did not spend the time to dig as deep into it).

I'll spend some time next week looking at the older reports we received, and if the issue is similar to this one. If we have a few popular sites with breakage caused by this, then it's probably worth to keep this open, but if this is a one-off, having this wontfix'ed for now probably also works, we can always re-evaluate if we find more issues down the road.