onclick event doesn't fire on empty fixed position elements

VERIFIED FIXED in mozilla1.9.1b2



11 years ago
10 years ago


(Reporter: io, Assigned: uriber)


(Blocks 1 bug, {regression, testcase, verified1.9.1})

Dependency tree / graph
Bug Flags:
blocking1.9.1 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)




(4 attachments)



11 years ago
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.

Comment 1

11 years ago
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.

Comment 2

11 years ago
Further experimentation reveals that onmouseup also fails to fire but onmousedown fires as expected.


11 years ago
Version: unspecified → 3.0 Branch
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
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.



Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080814020606 Minefield/3.1a2pre ID:20080814020606



Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080815020705 Minefield/3.1a2pre ID:20080815020705
Keywords: regression
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:
(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).
Blocks: 262306
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Keywords: testcase
OS: Mac OS X → All
Hardware: Macintosh → All

Comment 8

11 years ago
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

Comment 9

11 years ago
Posted patch patchSplinter Review
Use GetFrameForNodeOffset(), not GetPrimaryFrameFor().
Attachment #341961 - Flags: review?(roc)
Comment on attachment 341961 [details] [diff] [review]

It would probably be quite easy to write a mochitest for this.
Attachment #341961 - Flags: superreview+
Attachment #341961 - Flags: review?(roc)
Attachment #341961 - Flags: review+
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.
Flags: in-testsuite?

Comment 13

11 years ago
Fixed with http://hg.mozilla.org/mozilla-central/rev/5ab2c2b2f3a0. I'll work on a mochitest (Martijn, I might need your help for this).
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.
Posted patch mochitestSplinter Review
This is untested yet, because xpcshell.exe keeps crashing on me all the time, while trying to run the mochitests (bug 442192).

Comment 16

11 years ago
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.


11 years ago
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Flags: blocking1.9.1+
Keywords: fixed1.9.1
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


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090720
Shiretoko/3.5.1pre ID:20090720042942
You need to log in before you can comment on or make changes to this bug.