458418 - onclick event doesn't fire on empty fixed position elements

Status: VERIFIED FIXED

(Core :: DOM: Events, defect, P1)

Description

[Shaun Inman]

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

[Shaun Inman]

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

[Shaun Inman]

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

Comment 3

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 4

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 5

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 6

[Martijn Wargers (dead)]

Attachment: testcase attached to the bug

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?

Comment 7

[Martijn Wargers (dead)]

Yes, backing out the patch from bug 262306 fixes it for me in my debug build (unfortunately).

Comment 8

[Uri Bernstein]

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.

Comment 9

[Uri Bernstein]

Attachment: patch

Use GetFrameForNodeOffset(), not GetPrimaryFrameFor().

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 341961 [details] [diff] [review]
patch

It would probably be quite easy to write a mochitest for this.

Comment 11

[Ashley Bischoff (blog at handcoding.com)]

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?)

Comment 12

[Martijn Wargers (dead)]

The patch is already reviewed and is ready to land. But Uri probably wants to land this himself. Just be patient.

Comment 13

[Uri Bernstein]

Fixed with http://hg.mozilla.org/mozilla-central/rev/5ab2c2b2f3a0. I'll work on a mochitest (Martijn, I might need your help for this).

Comment 14

[Martijn Wargers (dead)]

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.

Comment 15

[Martijn Wargers (dead)]

Attachment: mochitest

This is untested yet, because xpcshell.exe keeps crashing on me all the time, while trying to run the mochitests (bug 442192).

Comment 16

[Kent Fredric]

Attachment: Position:fixed + Opacity test case

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.

Comment 17

[Aakash Desai [:aakashd]]

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:1.9.1.1pre) Gecko/20090720
Shiretoko/3.5.1pre ID:20090720042942