1258884 - Clicks on images are lost after bug 1226904's patch, in 3d-transform "coverflow" demo

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Loic]

Fllow-up of https://bugzilla.mozilla.org/show_bug.cgi?id=790239#c2

STR: 
Open the testcase https://bugzilla.mozilla.org/attachment.cgi?id=8733614 and click on the tiles to switch them.

Result: clicking on tiles on the left doesn't trigger transform, you have to click on the extreme left.

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6c49bb716593014c07d3736ea2124f74bfe3bb06&tochange=691f2e687e46d1b166b88b0a3f9dbd480bff9afa

Thinker K.F. Li — Bug 1226904 - Fix boundary checking for leaves collecting. r=roc

Comment 1

[Daniel Holbert [:dholbert]]

I can reproduce in 64-bit nightly on Linux.

Comment 2

[Thinker Li [:sinker]]

The root cause at here is the same as bug 1232060.  The background of the parent is above children, and it intercepts all events.  It means the target of all events is always the parent itself.  The solution
is to remove preserve-3d on the parent, or add a translation on z-axis to make all children above the background.

Comment 3

[Thinker Li [:sinker]]

More information!  The children overflow the parent, so the background cover only the left side, that is why click at right side work, but not for left.

Comment 4

[Doug Turner (:dougt)]

assign to tlee.

Comment 5

[Jet Villegas (inactive)]

I think we n(In reply to Thinker Li [:sinker] from comment #2)
> The root cause at here is the same as bug 1232060.  The background of the
> parent is above children, and it intercepts all events.  It means the target
> of all events is always the parent itself.  The solution
> is to remove preserve-3d on the parent, or add a translation on z-axis to
> make all children above the background.

(In reply to Thinker Li [:sinker] from comment #3)
> More information!  The children overflow the parent, so the background cover
> only the left side, that is why click at right side work, but not for left.

In other words, you're asserting that the test is incorrect. Please post a patch that corrects the test in bug 790239. With bug 1232060, we had YouTube fix their site. If we find public sites that count on this behavior, we may revisit the decision to fix bug 1226904.

Comment 6

[Thinker Li [:sinker]]

Ok! I would do.

Comment 7

[Liz Henry (:lizzard)]

I'm not clear if I need to be tracking this bug, but I don't think so. 
Is it just a test issue? Do we have any examples of this happening on current sites?    
Daniel or Matt what do you think?

Comment 8

[Daniel Holbert [:dholbert]]

I believe this was just an issue with a demo going from working to broken.  But from recent comments here, it sounds like our new behavior is actually more correct than our old behavior (and more correct than Chrome's behavior per [1]), and the demo was making a mistaken assumption.

So, I agree we don't need to be tracking this bug.

> Do we have any examples of this happening on current sites?

(I don't believe we have any URLs of affected sites, but I assume there's *some* actual website that uses this, which the reporter in bug 790239 [the source of our testcase] was developing and/or using. I'll post a comment over on that bug to make sure the reporter is aware that the demo is making a mistaken assumption, & to see if there's any additional tech evang that we need to do about this.)

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=585285

Comment 9

[Liz Henry (:lizzard)]

Thanks very much for the explanation and followup!

Comment 10

[Liz Henry (:lizzard)]

Looking back at this as it popped up in triage again. 
Let's mark this WORKSFORME as we don't have any current examples of it not working (from https://bugzilla.mozilla.org/show_bug.cgi?id=790239#c8)

Comment 11

[Lawrence Mandel [:lmandel] (use needinfo)]

Changed status flags to represent worksforme status.

Comment 12

[Daniel Holbert [:dholbert]]

Sorry, this isn't technically WORKSFORME (that would mean it just started working for some unknown reason, but that's not the case).

Rather, it's INVALID, in that the reported behavior is actually a bug in the testcase and not in Firefox.

--> correcting resolution, and clearing status flags since "unaffected" gives the false impression that the issue doesn't reproduce with those versions. (It does reproduce; it's just a bug in the testcase.)