Last Comment Bug 656749 - If Opacity is set to zero SWF Objects will not respond to click handler events
: If Opacity is set to zero SWF Objects will not respond to click handler events
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: mozilla6
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
: Benjamin Smedberg [:bsmedberg]
Mentors:
http://kinzin.com/misc/upload_test
Depends on:
Blocks: 519144
  Show dependency treegraph
 
Reported: 2011-05-12 13:59 PDT by Cory
Modified: 2011-05-23 18:32 PDT (History)
7 users (show)
roc: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (3.53 KB, patch)
2011-05-16 02:56 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
tnikkel: review+
Details | Diff | Splinter Review
fix v2 (3.04 KB, patch)
2011-05-18 22:41 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
tnikkel: review+
Details | Diff | Splinter Review

Description Cory 2011-05-12 13:59:15 PDT
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 2011-05-12 14:55:09 PDT
Maybe this is intentional behavior by Bug 519144 .
Comment 2 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-05-12 15:24:03 PDT
No, opacity:0 elements should get events.
Comment 3 Alice0775 White 2011-05-12 15:30:22 PDT
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 [:bz] (still a bit busy) 2011-05-12 17:35:39 PDT
Possible, but that patch _is_ checking IsForEventDelivery()...
Comment 5 Timothy Nikkel (:tnikkel) 2011-05-13 10:32:18 PDT
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) 2011-05-14 04:23:43 PDT
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) 2011-05-16 02:56:56 PDT
Created attachment 532587 [details] [diff] [review]
fix
Comment 8 Mounir Lamouri (:mounir) 2011-05-17 04:47:39 PDT
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) 2011-05-17 06:29:46 PDT
It looks like this patch was the guilty one.
Comment 10 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-05-18 21:53:52 PDT
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) 2011-05-18 22:41:41 PDT
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.
Comment 12 Dão Gottwald [:dao] 2011-05-18 23:34:25 PDT
(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) 2011-05-19 02:04:41 PDT
OK
Comment 14 Timothy Nikkel (:tnikkel) 2011-05-19 10:30:31 PDT
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) 2011-05-20 05:14:13 PDT
Thanks.
Comment 16 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-05-22 17:31:39 PDT
http://hg.mozilla.org/projects/cedar/rev/f147a447fff5
Comment 17 Matt Brubeck (:mbrubeck) 2011-05-23 08:46:22 PDT
http://hg.mozilla.org/mozilla-central/rev/f147a447fff5
Comment 18 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-05-23 18:32:04 PDT
I suspect this case is rare enough that we don't need to push the fix into FF5.

Note You need to log in before you can comment on or make changes to this bug.