1131961 - Events fail to fire correctly for large y values of transform: translate3d()

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Evan Trimboli]

Attachment: bug.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.94 Safari/537.36

Steps to reproduce:

Using the attached test case:

1) Click on the div with "1". Observe the event target.
2) Change the value in the input to 500000. Click go.
3) Click on the div with "1". Observe the event target.
4) Change the value in the input to 550000. Click go.
5) Click on the div with "1". Observe the event target.


Actual results:

1) The event target is the clicked div.
2) The event target is the clicked div.
3) The event target is the container div.


Expected results:

1) The event target is the clicked div.
2) The event target is the clicked div.
3) The event target is the clicked div.

Comment 1

[Evan Trimboli]

This was also tested using the latest nightly 38.0a1 (2015-02-10).

The test case above is a simplified version of something we're doing in the framework to create a grid with buffered rendering.

Comment 2

[Alice0775 White]

Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/93b66a3f8e7d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140707214932
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/15b924cf6eab
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140707215730
Pushlog;
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=93b66a3f8e7d&tochange=15b924cf6eab
Regressed by:
15b924cf6eab	Matt Woodrow — Bug 1031948 - Cull points that have w <= 0 when untransforming layer coordinates. r=bjacob

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

Matt/Benoit - can someone look into this?  Though it's been regressed for a while in mainline FF, 38 is the next major version of ESR so it would be good to find a forward fix or a backout that can restore this functionality to equal ESR31.

Note to reporter, since Firefox 38 *is* the ESR38 release there is no need to track this for ESR38 separately.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

I'm no longer working at Mozilla, sorry.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

I tried reproducing with a debug build that includes the change from 1031948 and it did not reproduce...

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

Evan, do you still see this problem?

Comment 7

[Alice0775 White]

I can still reproduce the event problem

https://hg.mozilla.org/mozilla-central/rev/e046475a75cb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 ID:20150327030212

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

It's unclear to me what "observe event target" means and what happens when we fail to do the right thing.

Comment 9

[Evan Trimboli]

Observe the event target means look at the event target that is logged to the console. As the translate3d value gets large enough, the event target from the click listener is no longer correct, it logs the containining element as opposed to the actual element that was clicked. 

The click with the input value as 0 & 500000 log '<div style="border: 1px solid red;">'.
The click with the input value as 550000 logs '<div style="width: 300px; position: relative; transform: translate3d(0px, 550000px, 0px);">'

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

Thanks; that's what I thought, but since I couldn't reproduce the problem, I wanted to make sure I was looking for the right thing.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Milan, do you have an idea on who could help us with this bug? Thanks

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

Big part of it is being able to reproduce :)  Kip, you looked recently at transforms and such, can you reproduce this problem?

Comment 13

[:kip (Kearwood Gilbert)]

I have reproduced this in the latest nightly on OSX 10.10, and can take this bug.  I am familiar with the code in the regressing patch.

Comment 14

[Evan Trimboli]

Can confirm this still occurs on 40.0a1 (2015-04-08), tested on Windows 7.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Wontfix for 38. We could take a patch for 39.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Kip is this still something you might work on for 39? We could still take a fix for this in early beta.

Comment 17

[:kip (Kearwood Gilbert)]

(In reply to Liz Henry (:lizzard) from comment #16)
> Kip is this still something you might work on for 39? We could still take a
> fix for this in early beta.
Initially I thought this was related to CSS transforms and clipping issues; however, it appears to be more related to numerical precision when very large offsets are applied and/or clamping of position somewhere else.  I am currently focusing on CSS transform clipping issues, so it may be that someone else may get this fixed earlier.

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

We are heading into beta 4 now so are unlikely to take an uplift. This could still be fixed for 40 though.

Comment 19

[u279076]

Milan, looks like this has been de-prioritized. It's been several months, is this something we still need to track?

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

Track, no, but leave it open.

Comment 21

[rlayeh]

Hello
This bug is quite annoying.
You can also reproduce it with this fiddle: http://jsfiddle.net/84Lako6t/2/

Modify TRANSLATE_MODIFIER value to check behavior (hoover over test rows).
If value is set to 500000 everything is ok but everything above 524288 will not work anymore.

We are using a library which is using translate3d to calculate offsets for rows in a grid (with a virtual scrolling). 
Currently it is not working on firefox correctly because of this bug.

Comment 22

[Matt Woodrow (:mattwoodrow)]

I can't reproduce this on Nightly, it was probably fixed by bug 1217012.

Can you confirm please? We can probably get it uplifted to Aurora at least.

Comment 23

[rlayeh]

It looks like it is fixed in newest Nightly build.

Comment 24

[u279076]

Closing based on comment 23.