1.13 KB, text/html
1.98 KB, patch
|Details | Diff | Splinter Review|
3.62 KB, patch
|Details | Diff | Splinter Review|
1.20 KB, text/html
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us) AppleWebKit/526.11 (KHTML, like Gecko) Version/4.0dp1 Safari/526.11.2 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2) Gecko/20080829065003 Shiretoko/3.1a2 The onclick event doesn't fire when an empty fixed position element is clicked. Reproducible: Always Steps to Reproduce: Visit http://shauninman.com/tmp/ff31.html. Click each colored box. Actual Results: Three boxes alert "clicked" when clicked. The second blue box does not. Expected Results: All four boxes should alert "clicked" when clicked. I haven't done extensive testing but only position:fixed; appears to trigger this bug. position:absolute works as expected.
I just noticed that my reduction conceals a larger problem. Even if the element contains another element (is not empty) and that nested element is set to display:none; the fixed positioned parent element still doesn't fire the onclick event when clicked. If the nested element is visible, only clicking the contents of that nested element triggers the parent elements onclick event. For example, if the parent element has padding, clicking the area representing the parent's padding will not fire the onclick event.
Further experimentation reveals that onmouseup also fails to fire but onmousedown fires as expected.
Confirming and marking NEW with Build ID: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081003 Minefield/3.1b1pre -> Core -> DOM Events
Status: UNCONFIRMED → NEW
Component: General → DOM: Events
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → events
Version: 3.0 Branch → Trunk
I've narrowed down the regression window a bit. In short, 2008-08-14-020606 was ok while 2008-08-15-020705 was bad. --- (Ok) Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080814020606 Minefield/3.1a2pre ID:20080814020606 --- (Bad) Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080815020705 Minefield/3.1a2pre ID:20080815020705
Assuming I did the Bonsai query correctly, I believe this displays the checkins between between 2008-08-14 00:00 and 2008-08-15 00:00 : http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-08-14&maxdate=2008-08-15&cvsroot=%2Fcvsroot
Thanks for the regression range. Since this is a regression in the Firefox3.1 builds, you need this query to find out what checkin might have caused it: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-08-14+02%3A00%3A00&enddate=2008-08-15+09%3A00%3A00 (this is from http://hg.mozilla.org/mozilla-central/pushloghtml ) Perhaps regression from bug 262306?
Yes, backing out the patch from bug 262306 fixes it for me in my debug build (unfortunately).
OS: Mac OS X → All
Hardware: Macintosh → All
I used GetPrimaryFrameFor() instead of GetFrameForNodeOffset(). Shame on me, since this is the second time I make this mistake. I'll try to have a patch posted tomorrow.
Assignee: nobody → uriber
Status: NEW → ASSIGNED
Use GetFrameForNodeOffset(), not GetPrimaryFrameFor().
Comment on attachment 341961 [details] [diff] [review] patch It would probably be quite easy to write a mochitest for this.
Robert: Would you be the right person to review Uri's patch or would someone else be more suitable for that? (Or do we first need to see what the outcome is on the "blocking1.9.1?" / "wanted1.9.1?" flags?)
The patch is already reviewed and is ready to land. But Uri probably wants to land this himself. Just be patient.
Fixed with http://hg.mozilla.org/mozilla-central/rev/5ab2c2b2f3a0. I'll work on a mochitest (Martijn, I might need your help for this).
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2
I was trying to come up with a mochitest, but I noticed some strange behavior, like click events not firing, so I filed bug 459222 for that. I still think it's possible to come up with a mochitest for this (I'll do this), but that got me confused for a while.
This is untested yet, because xpcshell.exe keeps crashing on me all the time, while trying to run the mochitests (bug 442192).
Took me a while to find this bug as initially thought it was a problem with opacity. I had to author a test case before discovering the problem was position:fixed causing the problem. ( 3.1 Beta 1 ) This has an interesting side effect in that in combination with opacity, the transparent layer doesn't receive clicks, but still transmits some mouse information to the next layer( noted by the fact you can still select text on the underlying layer ). Hopefully this text will aide others finding this bug , as this is likely to occur in many of the modal layered "lightbox" tools.
Priority: -- → P1
verified FIXED using the attached testcases on builds: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090721 Minefield/3.6a1pre ID:20090721044139 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/20090720 Shiretoko/3.5.1pre ID:20090720042942
You need to log in before you can comment on or make changes to this bug.