The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla6

Status

()

Core
Plug-ins
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Cory, Assigned: roc)

Tracking

Trunk
mozilla6
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

6 years ago
Maybe this is intentional behavior by Bug 519144 .
No, opacity:0 elements should get events.

Comment 3

6 years ago
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.
Created attachment 532587 [details] [diff] [review]
fix
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.
Created attachment 533541 [details] [diff] [review]
fix v2

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).
OK
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]
http://hg.mozilla.org/projects/cedar/rev/f147a447fff5
Whiteboard: [needs landing] → [fixed-in-cedar]
Flags: in-testsuite+
http://hg.mozilla.org/mozilla-central/rev/f147a447fff5
Status: ASSIGNED → RESOLVED
Last Resolved: 6 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.