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

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Cory]

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

Comment 1

[Alice0775 White]

Maybe this is intentional behavior by Bug 519144 .

Comment 2

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

No, opacity:0 elements should get events.

Comment 3

[Alice0775 White]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Possible, but that patch _is_ checking IsForEventDelivery()...

Comment 5

[Timothy Nikkel (:tnikkel)]

Perhaps we hid the plugin and/or its widget and so it doesn't get any events because of that?

Comment 6

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

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.

Comment 7

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

Attachment: fix

Comment 8

[Mounir Lamouri (:mounir)]

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

Comment 9

[Mounir Lamouri (:mounir)]

It looks like this patch was the guilty one.

Comment 10

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

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.

Comment 11

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

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

Comment 12

[Dão Gottwald [:dao]]

(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 13

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

OK

Comment 14

[Timothy Nikkel (:tnikkel)]

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.

Comment 15

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

Thanks.

Comment 16

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

http://hg.mozilla.org/projects/cedar/rev/f147a447fff5

Comment 17

[Matt Brubeck (:mbrubeck)]

http://hg.mozilla.org/mozilla-central/rev/f147a447fff5

Comment 18

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

I suspect this case is rare enough that we don't need to push the fix into FF5.