Created attachment 8562643 [details] 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.
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.
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
Status: UNCONFIRMED → NEW
status-firefox35: --- → affected
status-firefox36: --- → affected
status-firefox37: --- → affected
status-firefox38: --- → affected
status-firefox-esr31: --- → unaffected
status-firefox-esr38: --- → affected
tracking-firefox38: --- → ?
tracking-firefox-esr38: --- → ?
Component: Untriaged → Graphics: Layers
Ever confirmed: true
Product: Firefox → Core
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.
tracking-firefox38: ? → +
tracking-firefox-esr38: ? → ---
I'm no longer working at Mozilla, sorry.
I tried reproducing with a debug build that includes the change from 1031948 and it did not reproduce...
Evan, do you still see this problem?
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
status-firefox39: --- → affected
It's unclear to me what "observe event target" means and what happens when we fail to do the right thing.
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);">'
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.
Milan, do you have an idea on who could help us with this bug? Thanks
Big part of it is being able to reproduce :) Kip, you looked recently at transforms and such, can you reproduce this problem?
Flags: needinfo?(milan) → needinfo?(kgilbert)
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.
Can confirm this still occurs on 40.0a1 (2015-04-08), tested on Windows 7.
Wontfix for 38. We could take a patch for 39.
status-firefox35: affected → wontfix
status-firefox36: affected → wontfix
status-firefox37: affected → wontfix
status-firefox38: affected → wontfix
tracking-firefox39: --- → +
Kip is this still something you might work on for 39? We could still take a fix for this in early beta.
(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.
We are heading into beta 4 now so are unlikely to take an uplift. This could still be fixed for 40 though.
status-firefox39: affected → wontfix
status-firefox40: --- → affected
status-firefox41: --- → affected
4 years ago
Assignee: kgilbert → lsalzman
Milan, looks like this has been de-prioritized. It's been several months, is this something we still need to track?
status-firefox40: affected → wontfix
status-firefox41: affected → wontfix
status-firefox42: --- → affected
status-firefox43: --- → affected
status-firefox44: --- → affected
status-firefox45: --- → affected
tracking-firefox38: + → ---
tracking-firefox39: + → ---
Track, no, but leave it open.
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.
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.
It looks like it is fixed in newest Nightly build.
Closing based on comment 23.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox35: wontfix → ---
status-firefox36: wontfix → ---
status-firefox37: wontfix → ---
status-firefox38: wontfix → ---
status-firefox39: wontfix → ---
status-firefox40: wontfix → ---
status-firefox41: wontfix → ---
status-firefox42: affected → ---
status-firefox43: affected → ---
status-firefox44: affected → ---
status-firefox45: affected → ---
status-firefox-esr31: unaffected → ---
status-firefox-esr38: affected → ---
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.