Closed Bug 923527 Opened 11 years ago Closed 8 years ago

Shumway should honor the user's Flash click-to-play settings for the Flash plugin

Categories

(Firefox :: Settings UI, defect)

x86_64
Windows 8
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: kyle.leet, Assigned: bugs)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20131003030203

Steps to reproduce:

Enabled Shumway, tried to play media using Shumway. Media didn't play, clicked the Shumway text at the bottom of the window, Flash launched bypassing my plugins.click_to_play setting.


Actual results:

Flash launched and destroyed my system audio.


Expected results:

Flash shouldn't have loaded.
It looks like Flash is continuing to load by default after being invoked by clicking the Shumway text (it's still blocked in the new windows). Loading Youtube reproduces this.

http://www.bbc.co.uk/programmes/b03bpyt8 was the media that caused this initially.
Blocks: shumway
Component: Untriaged → Shumway
The purpose of the "shumway" button is to launch flash: it is the click-to-play button. It's not great UI and will certainly be removed/changed later, but that's what the button is for.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> The purpose of the "shumway" button is to launch flash: it is the
> click-to-play button.

FireFox and the Click-To-Play system don't see this as being "the button". If they did, I'd be inclined to agree.

http://puu.sh/4JsLw.png - Shumway
http://puu.sh/4JsLR.png - Shumway Exploit bypassing Click-To-Play.

Maybe I'm just seeing this as broken implementation when it is in fact deliberate?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
I'm not sure what comment #3 or the screenshots are indicating. You started one particular instance of Flash using the shumway button. That doesn't affect the general state of Flash in the doorhanger, so everything looks correct as far as I can tell.
Flags: needinfo?(kyle.leet)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> I'm not sure what comment #3 or the screenshots are indicating. You started
> one particular instance of Flash using the shumway button. That doesn't
> affect the general state of Flash in the doorhanger, so everything looks
> correct as far as I can tell.

This is the past, correct behaviour of click-to-play. The current broken behaviour is all or nothing from a site. This doesn't line up with how click-to-play currently functions in Firefox. Bug 886792 covers the regression quite well in regards to click-to-play in general. Consistent behaviour from Firefox is all I'm after.
Flags: needinfo?(kyle.leet)
See Also: → CTP-perelement
There's two bugs here with Shumway. Shumway is explicitly disabled on sites like YouTube. This explicitly bypasses Click-To-Play without clicking on the Shumway text. This is definitely completely broken.
(In reply to Kyle Sanderson from comment #6)
> Shumway is explicitly disabled on sites like YouTube
Known issue:
"You should not expect miracles right now though. A quick test on popular sites such as Kongregate or YouTube turned out that it is not really able to replace Flash just yet on these sites. It did not work at all on YouTube for example, with Flash being used automatically on the site even though click to play was enabled. On Kongregate, games would not load but display the Shumway logo in the lower corner."
http://www.ghacks.net/2013/10/02/mozillas-flash-plugin-replacement-shumway-lands-firefox-nightly/
That seems like it might be an intentional choice:
To provide a seamless experience where Shumway is known to not work, Flash is explicitly run for that content (until Shumway is more complete later on and we can stop doing that).

Till, maybe you can clarify?
Flags: needinfo?(till)
While we indeed do blacklisting of pages that we know not to work right now (and will certainly extend that list for a while instead of shrinking it), not showing the click-to-play UI for those sites is not intentional.

A click on the Shumway bottom on pages where we do activate Shumway, however, is intended to immediately start the Flash Player. Bsmedberg is spot-on in comment 4: it's terrible UI. We know. We will make it better.

needinfo?-ing yury for the skipping-click-to-play part.
Flags: needinfo?(till) → needinfo?(ydelendik)
(In reply to Till Schneidereit [:till] from comment #9)
> A click on the Shumway bottom on pages where we do activate Shumway,
> however, is intended to immediately start the Flash Player. Bsmedberg is
> spot-on in comment 4: it's terrible UI. We know. We will make it better.
The biggest problem with that UI is (IMO) that it only handles visible content. I was confused by the fact that chat on twitch.tv was broken by Shumway, but it turns out they use Flash under the hood for it (even though the UI doesn't).
(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #10)
> The biggest problem with that UI is (IMO) that it only handles visible
> content. I was confused by the fact that chat on twitch.tv was broken by
> Shumway, but it turns out they use Flash under the hood for it (even though
> the UI doesn't).

I agree: that's bad. I'm not entirely sure what we can do about it, though. Just having an icon in the url bar indicating that Shumway is used and disabling it seems fairly undiscoverable. Showing a yellow warning bar, OTOH, seems overly intrusive. We should talk about this with UX people, I guess.
This bug should only track the issue where we're launching Flash automatically on youtube. The other issue about discoverability of hidden elements is out of scope, especially because we don't have a product plan for shumway on desktop yet.
I am experiencing same issue.

Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131127030201 CSet: 6ecf0c4dfcbe
shumway.ignoreCTP (boolean) is set to false.
Partially fixed in upstream at https://github.com/mozilla/shumway/pull/1004

"Lego-block" screen is not visible. Sounds similar to bug 920927
Flags: needinfo?(ydelendik)
After nsObjectContent.cancelPlayPreview() call, the overlay UI controls are not rebound/initialized with standard click-to-play stuff -- the PluginClickToPlay eventType is not "called". Looks like cancelPlayPreview got broken after bug 800018.

John, what would be the easiest way to restore this functionality?
Flags: needinfo?(jschoenick)
Bug 558184 reworks most of this, and should fix the issues, but I'll have to double-check why the event isn't firing here, or if its firing and the front end is ignoring it.
Assignee: nobody → jschoenick
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(jschoenick)
See Also: → 958965
See Also: 958965
Blocks: 958965
Whiteboard: [shumway:m2]
Whiteboard: [shumway:m2] → [shumway:p1]
In our Shumway UX meeting this morning, we decided that Shumway should honor the user's click-to-play settings for the Flash plugin. This includes per-site click-to-play settings.

If the user does not have Flash installed, then Shumway should be disabled by default but can be enabled with a pref. (TBD: the "shumway.disabled" pref?)
Assignee: john → nobody
Summary: Shumway bypasses Click To Play. → Shumway should honor the user's Flash click-to-play settings for the Flash plugin
Philipp, can you explain your reasoning for this? I'm surprised that we'd make Shumway affected by Flash settings.
Flags: needinfo?(philipp)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #18)
> Philipp, can you explain your reasoning for this? I'm surprised that we'd
> make Shumway affected by Flash settings.

People who have click-to-play enabled currently don't see Flash ads. Ignoring that setting means that they update Firefox and all of a sudden see Flash ads again, so we regressed their user experience.

Another option would be to do a one-time migration where we set click-to-play to whatever the user has currently set for Flash, but after that have Shumway's setting be independent.
We made this click-to-play decision only considering Flash ads for Shumway's initial release.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #18)
> Philipp, can you explain your reasoning for this? I'm surprised that we'd
> make Shumway affected by Flash settings.

What Till said.

The short answer is: because Shumway is "just" a different player for Flash content. We should avoid having the think about the distinction of Shumway playing SWFs versus Flash player doing that. If there actually is a group of people who wants Flash ads but not other Flash content, it is probably comprised of people who can be entrusted with changing an about:config pref.
Flags: needinfo?(philipp)
This decision has unfortunate consequences. The primary way users will experience click-to-play of Flash is when Flash is vulnerable, and we'd like to be able to deploy vulnerability blocks much more aggressively as a result of having Shumway.

The click-to-activate settings were intended as a way to control 3rd-party software in the browser, and not as a content blocking mechanism. We should at least decouple the case where Flash is click-to-play because of a vulnerability: in that case SWF content rendered using Shumway should not be affected. But I really do believe that we should just always use shumway without regard to the CtA state of Flash, and if people want to block Flash content, they can use something like Flashblock.
What do you think about at least migrating people's preference over, then? I don't know how feasible it is, but ISTM somebody who has explicitly opted to make Flash click-to-play would experience Shumway playing it by default as a serious regression, and would very much like to avoid that.
I don't mind that, but in the current design there is no preference, since Shumway doesn't appear in the addons manager. So we'd have to have some UI to disable/enable/CtA Shumway separately.

Talked with phlsa briefly on IRC; not sure what he wants to do with this. I recommend straight-up WONTFIX.
Flags: needinfo?(philipp)
Shumway will show up in the plugins list once it's moved to jsplugins. (In fact, we'd have to add hacks for it *not* to show up.)

Do we have numbers on how many people have manually set Flash to click-to-play?
The UX notes at https://docs.google.com/a/mozilla.com/document/d/1gQKYJPTCVbuucc6IASftrknp9tZvmkwmsVhZpr7rinY/edit say that shumway should not appear in the addons manager.
Right. I contend that either it should, or it should follow whatever is set for Flash in that UI. Hiding it and not making it follow the Flash settings strictly reduces control, which is particularly bad given the intended initial use-case.
Assuming Shumway can differentiate between Flash being click-to-play because of user action vs a vulnerability block, I suggest:

- On install (whatever that means), Shumway inherits the user's click-to-play setting for Flash, ignoring a vulnerability block.
- Shumway be listed in the Add-on Manager's Plugin tab, so users can configure both Shumway's and Flash's click-to-play settings.
- Shumway is always wins over Flash unless Shumway=Never Activate.
Especially if we ship Shumway enabled-by-default this will be a big regression for users that have explicitly made Flash click-to-activate. I really think we should support that use case somehow and try not to alienate our advanced users.
IMHO users set Flash to CTP to avoid Flash Content and use an AdBlocker to hide (Flash) Ads.
(In reply to Chris Peterson [:cpeterson] from comment #28)
> Assuming Shumway can differentiate between Flash being click-to-play because
> of user action vs a vulnerability block, I suggest:
> 
> - On install (whatever that means), Shumway inherits the user's
> click-to-play setting for Flash, ignoring a vulnerability block.
> - Shumway be listed in the Add-on Manager's Plugin tab, so users can
> configure both Shumway's and Flash's click-to-play settings.
> - Shumway is always wins over Flash unless Shumway=Never Activate.

Sounds like a plan.
In that case it would be good to have a more accessible name for Shumway to present to the user in the plugin manager though.
Flags: needinfo?(philipp)
(In reply to Philipp Sackl [:phlsa] please use needinfo to make me respond from comment #31)
> In that case it would be good to have a more accessible name for Shumway to
> present to the user in the plugin manager though.

Yes, we're working on. :)
Assignee: nobody → bugs
Whiteboard: [shumway:p1]
(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #31)
> > - On install (whatever that means), Shumway inherits the user's
> > click-to-play setting for Flash, ignoring a vulnerability block.


In the case of Flash ads, when both Shumway and Flash click-to-play are enabled, the desired result is that clicking-to-play will start up Shumway and not the Flash Player, correct?
Flags: needinfo?(philipp)
(In reply to Jet Villegas (:jet) from comment #33)
> (In reply to Philipp Sackl [:phlsa] please use needinfo from comment #31)
> > > - On install (whatever that means), Shumway inherits the user's
> > > click-to-play setting for Flash, ignoring a vulnerability block.
> 
> 
> In the case of Flash ads, when both Shumway and Flash click-to-play are
> enabled, the desired result is that clicking-to-play will start up Shumway
> and not the Flash Player, correct?

Yeah, that sounds right.
Flags: needinfo?(philipp)
Product: Firefox → Firefox Graveyard
Status: ASSIGNED → RESOLVED
Closed: 11 years ago8 years ago
Resolution: --- → INCOMPLETE
No part of this bug needs more information.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Component: Shumway → Preferences
Product: Firefox Graveyard → Firefox
Mozilla is not actively working on Shumway right now. Bug reports or fixes can be submitted on GitHub:

https://github.com/mozilla/shumway/
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.