User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 FirePHP/0.5
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 FirePHP/0.5
Firefox Version : 4.0, 4.0.1
OS Version: OS X 10.6.7
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5: PASS
Chrome 10: PASS
IE 8 : PASS
Firefox 3.6.3: PASS
<object> tags loading a SWF object will fail to respond to click events if the opacity is set to zero. Behavior has changed between Firefox versions, this does not occur in FF 3.6.3. A workaround is to set the opacity to almost zero (0.001). Please see http://kinzin.com/misc/upload_test for code and test cases.
border: 1px solid red;
<div>Click Below - With Opacity 0.01</div>
Steps to Reproduce:
1. Load <object> with SWF
2. Set opacity to 0
3. No longer responds to click events
Would expect <object> to respond to click events.
Tested on OSX 10.6.7 and XP SP2
Maybe this is intentional behavior by Bug 519144 .
No, opacity:0 elements should get events.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091026 Minefield/3.7a1pre ID:20091026045849
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091027 Minefield/3.7a1pre ID:20091027043823
cset 27c92be3d840 of Bug 519144.
Possible, but that patch _is_ checking IsForEventDelivery()...
Perhaps we hid the plugin and/or its widget and so it doesn't get any events because of that?
We hide its widget, I bet that's why it doesn't get mouse clicks.
I guess where we check IsForEventDelivery we should actually check !IsForPainting.
Created attachment 532587 [details] [diff] [review]
Roc pushed this patch on cedar and it has been backed out because it's suspected of creating a perma-orange on Windows Mochitest-4:
It looks like this patch was the guilty one.
So the reason the tests failed is that there is an opacity:0 element covering these test plugins! It's the hidden statuspanel, which apparently has been hidden by making it opacity:0.
Dao, any particular reason why you don't make it display:none instead? That would reduce overhead.
Created attachment 533541 [details] [diff] [review]
Ensure opacity:0 chrome elements are not treated as opaque when computing plugin visibility (change to TreatAsOpaque).
Note that plugins in opacity:0 chrome elements would still work for accepting events, if anyone was crazy enough to want to do that.
Passes the tests that failed previously.
(In reply to comment #10)
> Dao, any particular reason why you don't make it display:none instead? That
> would reduce overhead.
display:none isn't being used in order to allow the status panel to fade in (using -moz-transition and opacity).
Comment on attachment 533541 [details] [diff] [review]
Looks like the contents of your test file got lost in this patch. You might want to look into that and make sure the test gets in.
I suspect this case is rare enough that we don't need to push the fix into FF5.