Closed Bug 656749 Opened 11 years ago Closed 11 years ago

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

Categories

(Core Graveyard :: Plug-ins, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla6

People

(Reporter: cory, Assigned: roc)

References

()

Details

Attachments

(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) :
  http://kinzin.com/misc/upload_test

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

Issue:
<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.  

Sample code:
    <style>
      .target{
        padding:10px;
        border: 1px solid red;
      }
      .opacity-zero{
        opacity:0;
      }
      .opacity-almostzero{
        opacity:0.01;
      }
    </style>

      <div class="target">
        <object width="100%" height="24" data="/javascripts/lib/swfupload/Flash/swfupload.swf" class="opacity-zero" id="SWFUpload_0"></object>
      </div>
      <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>
      </div>


Reproducible: Always

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

Actual Results:  
Nothing

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.
OK

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/5f0bd7129549
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091026 Minefield/3.7a1pre ID:20091026045849
Fails:
http://hg.mozilla.org/mozilla-central/rev/2e01e97f9ded
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091027 Minefield/3.7a1pre ID:20091027043823
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5f0bd7129549&tochange=2e01e97f9ded
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:
http://tinderbox.mozilla.org/showlog.cgi?log=Cedar/1305628182.1305628854.5624.gz&fulltext=1
Assignee: nobody → roc
Status: UNCONFIRMED → ASSIGNED
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+
Thanks.
Whiteboard: [needs landing]
Flags: in-testsuite+
http://hg.mozilla.org/mozilla-central/rev/f147a447fff5
Status: ASSIGNED → RESOLVED
Closed: 11 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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.