744745 - Click to play overlay not appearing on vimeo.com

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Bartosz Piec]

Attachment: Problem example on vimeo.com

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.

Comment 1

[Jesper Hansen]

Is javascript disabled?

Comment 2

[Paul Rouget [:paul]]

I can reproduce.

Comment 3

[Bartosz Piec]

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

No.

Comment 4

[Jesper Hansen]

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

Comment 5

[Bartosz Piec]

(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).

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

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.

Comment 7

[Paul Rouget [:paul]]

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

Comment 8

[Justin Dolske [:Dolske]]

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

Comment 9

[Florian Bender]

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.

Comment 10

[Ian Melven :imelven]

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

Comment 11

[Florian Bender]

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

Comment 12

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

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

Comment 13

[Florian Bender]

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

Comment 14

[[e-mail]]

Attachment: Possible patch

Comment 15

[Jared Wein [:jaws] (please needinfo? me)]

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

Comment 16

[Jared Wein [:jaws] (please needinfo? me)]

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

Comment 17

[[e-mail]]

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

Comment 18

[[e-mail]]

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

Comment 19

[[e-mail]]

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

Comment 20

[Dirkjan Ochtman (:djc)]

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

Comment 21

[John Schoenick [:johns]]

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

Comment 22

[Jared Wein [:jaws] (please needinfo? me)]

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

Comment 23

[Georg Fritzsche [:gfritzsche]]

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.

Comment 24

[Georg Fritzsche [:gfritzsche]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #23)
> Loading that site

Sorry, that is: http://vimeo.com/39393474

Comment 25

[Georg Fritzsche [:gfritzsche]]

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?

Comment 26

[Karl Dubost]

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.

Comment 27

[Georg Fritzsche [:gfritzsche]]

Attachment: Prevent transparency from site CSS

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

Comment 28

[Georg Fritzsche [:gfritzsche]]

Attachment: Prevent transparency from site CSS, v2

Comment 29

[Benjamin Smedberg]

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.

Comment 30

[Georg Fritzsche [:gfritzsche]]

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

Comment 31

[Benjamin Smedberg]

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

Comment 32

[Georg Fritzsche [:gfritzsche]]

Attachment: Look without background-color override

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

Comment 33

[Benjamin Smedberg]

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

Comment 34

[Georg Fritzsche [:gfritzsche]]

Attachment: Prevent transparency from site CSS, v3

Removed background color over-ride.

Comment 35

[Jared Wein [:jaws] (please needinfo? me)]

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?

Comment 36

[Georg Fritzsche [:gfritzsche]]

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

No.

Comment 37

[Jared Wein [:jaws] (please needinfo? me)]

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

Comment 38

[Benjamin Smedberg]

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

Comment 39

[Jared Wein [:jaws] (please needinfo? me)]

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.

Comment 40

[Benjamin Smedberg]

UA !important is most precedent in our implementation.

Comment 41

[Jared Wein [:jaws] (please needinfo? me)]

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.

Comment 42

[Matthew N. [:MattN]]

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

Comment 43

[Georg Fritzsche [:gfritzsche]]

Attachment: Prevent transparency from site CSS, v4

Remove stray onload attribute in test caught by try.
Trivial change, so carrying over r+.

https://hg.mozilla.org/integration/mozilla-inbound/rev/65ea43f36e06

Comment 44

[Jared Wein [:jaws] (please needinfo? me)]

(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."

Comment 45

[Boris Zbarsky [:bzbarsky]]

> Can we make this cascade as a UA stylesheet

It already does afaict.

Comment 46

[Karl Dubost]

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 47

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/65ea43f36e06

Comment 48

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/65ea43f36e06

Comment 49

[Georg Fritzsche [:gfritzsche]]

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.

Comment 50

[Paul Silaghi, QA [:pauly]]

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

Comment 51

[Georg Fritzsche [:gfritzsche]]

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

Comment 52

[Paul Silaghi, QA [:pauly]]

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

Comment 53

[Paul Silaghi, QA [:pauly]]

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

Comment 54

[Georg Fritzsche [:gfritzsche]]

Paul, could you check wether ESR17 is affected?

Comment 55

[Paul Silaghi, QA [:pauly]]

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

Comment 56

[Georg Fritzsche [:gfritzsche]]

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.

Comment 57

[Georg Fritzsche [:gfritzsche]]

https://hg.mozilla.org/releases/mozilla-esr17/rev/ea2d0ddb08c6

Comment 58

[Paul Silaghi, QA [:pauly]]

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