User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120410 Firefox/14.0a1 Build ID: 20120410075652 Steps to reproduce: When Click to play is enabled the overlay for enabling flash is not visible on vimeo.com (maybe some other sites too). Clicking will enable the plugin though. It is visible on some other sites I visited. See http://vimeo.com/39393474 for an example and attached screenshot. Tested on latest nightly with fresh profile.

Is javascript disabled?

I can reproduce.

(In reply to Jesper Hansen from comment #1) > Is javascript disabled? No.

What is that inside the scrollbar in the More section on the page?

(In reply to Jesper Hansen from comment #4) > What is that inside the scrollbar in the More section on the page? There is the overlay (scrollbar is in flash) buy it is not visible on top of main video (big white space at the center).

Their object tag has class="an" where .an { opacity: 0 !important; }. When the plugin loads they remove the class. I'm not sure what is possible/friendly for us to do here.

(In reply to Jared Wein [:jaws] from comment #6) > I'm not sure what is possible/friendly for us to do here. To talk to them.

Hmm. Shouldn't we be able to have our UI explicitly set opacity to 1 (on our UI, not the <object>).

Can reproduce on Mac Lion, Fx 12b5 with NoScript (vimeo, vimeocdn and googlesyndication allowed). Luckily, I don't need to restart Fx when changing click_to_play in about:config.

(In reply to Florian Bender from comment #9) > Can reproduce on Mac Lion, Fx 12b5 with NoScript (vimeo, vimeocdn and > googlesyndication allowed). Luckily, I don't need to restart Fx when > changing click_to_play in about:config. This feature has only landed in Firefox 14, so this sounds like it may be a different bug perhaps ?

Funny thing is, it works perfectly right now ;-). Though it might be a NoScript oder Adblock Plus feature? Other possibly relevant addons I have installed are Cookie Monster, Firebug. See here for a screenshot of YouTube with plugins.click_to_play set to true: http://dl.dropbox.com/u/1536535/click_to_play.png

(In reply to Florian Bender from comment #11) > Funny thing is, it works perfectly right now ;-) The pref and some UI have been in the code for a little while now, due to it landing on mobile (hence the "tap here"). It almost certainly doesn't work like it should on desktop for earlier versions, though.

Well, after a bit more testing, it doesn't work very well. Except for blocking plugins ;-).

Comment on attachment 626754 [details] [diff] [review] Possible patch With this patch applied, the overlay is visible but clicking on it does not start the video. The .an class is still applied and the video can only be played when this class is removed. I tested the latter part out with DOM Inspector. Vimeo appears to have replaced their blank area with a poster image, so the importance of this bug is slightly reduced (although they lack a "play" indicator on their poster).

I used http://vimeo.com/10377992 for testing.

(In reply to Jared Wein from comment #16) > I used http://vimeo.com/10377992 for testing. Ah, I'd been testing on a vimeo video embedded on another site (sorry, I don't have the URL handy), where I was able to click the video even though the overlay wasn't visible, so I didn't realise that there was another issue.

(In reply to Jared Wein from comment #16) > I used http://vimeo.com/10377992 for testing. No problems here. Sorry it didn't work out for you.

Interestingly with the new click-to-play single plugin option, I now have to click twice to play an embedded vimeo video.

Yeah, this still happens, and it's kind of a pain.

Has anyone reached out to Vimeo on this? We have limited options for fixing this on our end.

I sent an email to support@vimeo about this. I will update here if/when I hear back.

Loading that site i only see a big image, clicking on it starts the flash player (both on 18 and trunk). That actually looks like a security issue with click-to-play to me.

(In reply to Georg Fritzsche [:gfritzsche] from comment #23) > Loading that site Sorry, that is: http://vimeo.com/39393474

Ok, so this is due to the opacity mentioned in the above comments, with the site setting the opacity for the click-to-play overlay. The overlay is not visible, but in front and thus receives the click. Can we get the opacity patch landed and uplifted?

Sometimes Vimeo employees are responsive on their own forums. http://vimeo.com/forums I see also a few of them CCed into that bugs. I will send an email to one contact person at vimeo.

Also needed to override the background-color from the default "transparent", otherwise the overlay would be partially transparent on the above site.

Comment on attachment 705328 [details] [diff] [review] Prevent transparency from site CSS, v2 I really don't think we want a background color. Please see the visual refresh in bug 831921.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #29) > I really don't think we want a background color. Please see the visual > refresh in bug 831921. Hm, i see. Any alternative suggestions on fixing the very transparent overlay on this site? I'm not entirely sure where this is coming from.

Why isn't it sufficient to force the correct transparency and skip the background color altogether?

This is how it looks like without the background-color adjustment. If that's fine maybe i just misunderstood the intentions?

Yes, I believe that is acceptable (and the simple UI will help also).

Removed background color over-ride.

Comment on attachment 705353 [details] [diff] [review] Prevent transparency from site CSS, v3 Review of attachment 705353 [details] [diff] [review]: ----------------------------------------------------------------- Will this work if we drop the '!important' from the property value?

(In reply to Jared Wein [:jaws] from comment #35) > Will this work if we drop the '!important' from the property value? No.

Comment on attachment 705353 [details] [diff] [review] Prevent transparency from site CSS, v3 Review of attachment 705353 [details] [diff] [review]: ----------------------------------------------------------------- OK, I'd like to get Dao's feedback on this change then. I'm fine with it, but I believe this would still mean that a site could override it if they added |opacity:0 !important|.

Hrm really? Can we make this cascade as a UA stylesheet so that our !important overrides the others?

Comment on attachment 705353 [details] [diff] [review] Prevent transparency from site CSS, v3 Review of attachment 705353 [details] [diff] [review]: ----------------------------------------------------------------- To be more clear, I'm just confused because I don't see where user agent important declarations fit in with http://www.w3.org/TR/CSS21/cascade.html#cascading-order.

UA !important is most precedent in our implementation.

Comment on attachment 705353 [details] [diff] [review] Prevent transparency from site CSS, v3 Review of attachment 705353 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for looking in to that Benjamin.

(In reply to Jared Wein [:jaws] from comment #39) > To be more clear, I'm just confused because I don't see where user agent > important declarations fit in with > http://www.w3.org/TR/CSS21/cascade.html#cascading-order. It's in CSS3.

Remove stray onload attribute in test caught by try. Trivial change, so carrying over r+. https://hg.mozilla.org/integration/mozilla-inbound/rev/65ea43f36e06

(In reply to Matthew N. [:MattN] from comment #42) > (In reply to Jared Wein [:jaws] from comment #39) > > To be more clear, I'm just confused because I don't see where user agent > > important declarations fit in with > > http://www.w3.org/TR/CSS21/cascade.html#cascading-order. > > It's in CSS3. For posterity, here is the section: http://www.w3.org/TR/css3-cascade/#important-rules "User agent stylesheets may also contain "!important" rules. These override all author and user rules."

> Can we make this cascade as a UA stylesheet It already does afaict.

Message from Andrew at vimeo: >Hi Karl- > >Thanks for reaching out, I'm glad so many people care about Vimeo working (and blocking Flash!) I've submitted this as a ticket to our player team. I'll let you know when they chime in with an answer. > >Andrew

Comment on attachment 705481 [details] [diff] [review] Prevent transparency from site CSS, v4 [Approval Request Comment] Bug caused by (feature/regressing bug #): click-to-play User impact if declined: Site CSS can make click-to-play overlay transparent, with it still receiving mouse-clicks, which enables tricking users into activating c2p plugins. Testing completed (on m-c, etc.): Local testing, test-suite coverage, landed fine on m-c. Risk to taking this patch (and alternatives if risky): Low-risk, it just forces opacity on the overlay. String or UUID changes made by this patch: none.

The overlay is properly displayed now on vimeo.com in Nightly 21.0a1 (2013-01-24). Verified fixed.

https://hg.mozilla.org/releases/mozilla-aurora/rev/026c4f71b37e https://hg.mozilla.org/releases/mozilla-beta/rev/eaa550566178

Verified fixed FF 19b4 Win7, Ubuntu 12.04, Mac OS X 10.7.5

Verified fixed Aurora 20.0a2 (2013-01-31) Win7, Ubuntu 12.04, Mac OS X 10.8.2

Paul, could you check wether ESR17 is affected?

Yes, it is - 2013-01-30-03-45-01-mozilla-esr17

Comment on attachment 705481 [details] [diff] [review] Prevent transparency from site CSS, v4 [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: Allows tricking the user into activating vulnerable plugins. User impact if declined: Site CSS can make click-to-play overlay transparent, with it still receiving mouse-clicks, which enables tricking users into activating c2p plugins. Fix Landed on Version: 19-21. Risk to taking this patch (and alternatives if risky): Low-risk, it just forces opacity on the click-to-play overlay. String or UUID changes made by this patch: None.

Verified fixed 2013-02-05-03-45-01-mozilla-esr17