Closed Bug 656749 Opened 10 years ago Closed 10 years ago

If Opacity is set to zero SWF Objects will not respond to click handler events


(Core :: Plug-ins, defect)

Not set





(Reporter: cory, Assigned: roc)





(1 file, 1 obsolete file)

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 for code and test cases.  

Sample code:
        border: 1px solid red;

      <div class="target">
        <object width="100%" height="24" data="/javascripts/lib/swfupload/Flash/swfupload.swf" class="opacity-zero" id="SWFUpload_0"></object>
      <div>Click Below - With Opacity 0.01</div>
      <div class="target">

        <object width="100%" height="24" data="/javascripts/lib/swfupload/Flash/swfupload.swf" class="opacity-almostzero" id="SWFUpload_1">&nbsp;</object>

Reproducible: Always

Steps to Reproduce:
1. Load <object> with SWF
2. Set opacity to 0
3. No longer responds to click events

Actual Results:  

Expected Results:  
Would expect <object> to respond to click events.

Tested on OSX 10.6.7 and XP SP2
Component: DOM: Core & HTML → Plug-ins
QA Contact: general → plugins
Maybe this is intentional behavior by Bug 519144 .
No, opacity:0 elements should get events.

Regression window:
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
Suspected bug:
cset 27c92be3d840 of Bug 519144.
Possible, but that patch _is_ checking IsForEventDelivery()...
Blocks: 519144
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.
Attached patch fix (obsolete) — Splinter Review
Attachment #532587 - Flags: review?(tnikkel)
Attachment #532587 - Flags: review?(tnikkel) → review+
Whiteboard: [needs landing]
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:
Assignee: nobody → roc
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
It looks like this patch was the guilty one.
Whiteboard: [needs landing]
Whiteboard: [fails moch-4 on Windows]
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.
Attached patch fix v2Splinter 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.
Attachment #532587 - Attachment is obsolete: true
Attachment #533541 - Flags: review?(tnikkel)
Whiteboard: [fails moch-4 on Windows]
(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]
fix v2

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.
Attachment #533541 - Flags: review?(tnikkel) → review+
Whiteboard: [needs landing]
Flags: in-testsuite+
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-cedar]
Target Milestone: --- → mozilla6
I suspect this case is rare enough that we don't need to push the fix into FF5.
You need to log in before you can comment on or make changes to this bug.