989014 - Event fluffing seems to ignore overflow: hidden

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Julien Wajsberg [:julienw] (PTO -> Aug 24)]

Attachment: fluffing-fails.html

STR:
* set "ui.mouse.radius.enabled" to true
* set "ui.mouse.radius.inputSource.touchOnly" to false
* load the attachment "fluffing-fails.html"
* tap below the "click above" button

Expected:
* nothing happens, or "click above" is displayed

Actual:
* "click below" is displayed


Now, if you load "fluffing-wins.html", you'll see everything works as expected.

Both files show a case where 2 elements are located in the same area, one is above the other. Obviously, the one that is below should not be clickable (unless it's visible).

The clickable link that's below contains a span with a background-color.

The difference between these 2 files is that in "fluffing-fails.html" the span has a fixed height and goes beyond the "a" boundary. Except the "a" element has a "overflow: hidden" css property so the span does not actually goes beyond the limit. You can remove this css property to see where the span would be without it. With the background-color we can clearly see that neither the <a> nor the <span> that are below are visible and so should not be clickable.

That's what happens if we disable event fluffing, but with event fluffing, it's made clickable.

I saw this issue while investigating bug 987445. I worked around the issue by making the <span> not exceed the <a> boundary, but the platform issue should be fixed nevertheless.

Comment 1

[Julien Wajsberg [:julienw] (PTO -> Aug 24)]

Attachment: fluffing-wins.html

Comment 2

[Julien Wajsberg [:julienw] (PTO -> Aug 24)]

Marking "regression" because we didn't have event fluffing in the past. To be sure, I checked in Firefox OS 1.1 and the issue does not reproduce.

Should we block a release for this?

Comment 3

[Jason Smith [:jsmith]]

This isn't a blocker - the only case we would hold a release on this would be for the earliest applicable partner facing release, which would be for 1.3. There's a workaround being implemented for 1.3, so that's sufficient here for now. However, if the issue here is more prominent to occur on the larger web platform, then we should re-evaluate whether we need this for 1.3 over the workaround in bug 987445.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

mats, roc, do we have any fast-enough solution to check overflow: hidden stuff, or would that
mean another hit test?
(I'm still paging in event fluffing code to my mind.)

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We could fix this reasonably easily by making GetClosest take clipping into account when computing 'region'.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

One option would be to grab the mVisibleRects from the display list and return those along with the frames in nsLayoutUtils::GetFramesForArea (or a new version of that). Then we use those visible rects as the basis of the region. Those rects are limited to the area we're searching within, and take into account clipping (but not occlusion culling since we don't do a ComputeVisibility pass). How does that sound, Mats?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Mats?

Comment 8

[Mats Palmgren (inactive)]

Comment 6 sounds fine, but it seems like more work than I have time for
at the moment.  I may get to it in a few weeks if no one else does.

Comment 9

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.