1192558 - CSS Hover-driven menus may not work correctly with event retargeting enabled, as the events go to nearby links instead

Status: RESOLVED FIXED

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

Description

[Evan Langlois]

User Agent: Mozilla/5.0 (Android; Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
Build ID: 20150625230915

Steps to reproduce:

This is a mobile/touch problem.  I use a set of menus in pure CSS (no javascript).  The initial menus drop-down just fine and I can select items in the menu except for an item that has no link.   It has a hover effect to trigger the opening of the submenu.  Firefox refuses to see the touch on this element to activate the menu.  Instead, it assumes I want the nearby links and directs the touch to one of them.   It should not make such assumptions.  Chrome works fine.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

This should be resolved with bug 1247095

Comment 2

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

Bug 1247095 was effectively reverted by bug 1618532, which means this bug is going to come back. Reopening to solve this better.

Comment 3

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

Attachment: Testcase

Here's a testcase, mostly stolen from https://css-tricks.com/solved-with-css-dropdown-menus/ with slight modifications. If I load this in GVE and try to click on the "Two" link to open the dropdown, it instead activates either "One" or "Three". If I wrap the "Two" text in a <a href="#"> tag then that doesn't happen and the "Two" submenu opens fine.

However I think if we disable event retargeting when the event target has a :hover effect that should solve this without requiring changes to the content.

Comment 4

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

Turns out the HasStateDependentStyle function that we used to use way back when for things like this doesn't exist any more, because it was really slow and got axed in the transition to stylo. Emilio says that implementing a function to do what we want (i.e. discover if there are any selectors on the page that are conditional on a particular element having the hover state) is going to be relatively annoying. It can be done, apparently, similar to how the HAS_SLOW_SELECTOR flag works, but is a bit of a hassle, and may not update properly if the relevant selectors are removed dynamically.

So for now I'm going to shelve this work, as we don't have any real "in the wild" examples of this happening. This is the only bug report I found that referenced this kind of scenario, and comment 0 doesn't provide any real-world URLs or examples to test against, so I'm not sure if the test case I attached in the previous comment is representative of real-world pages or not. If we do get reports of this being an issue we can revisit this and identify the best fix for those reports.

Moving to APZ component since we don't really have a dedicated component for event retargeting, and it's traditionally been maintained by APZ folks.

Comment 5

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

Bug 1632941 allowed elements with cursor:pointer to be fluff targets which fixes the test case here. If we run into other instances of this we can file other bugs.