Closed Bug 886792 (CTP-perelement) Opened 11 years ago Closed 11 years ago

[Regression] Click to play cannot play per each element

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: tetsuharu, Unassigned)

References

Details

(Keywords: regression) 

[Environment]
* http://hg.mozilla.org/mozilla-central/rev/bc569033125a

This is **regression**.
Click to play cannot play plugins per each element.
Blocks: 880735
Keywords: regression
See Also: → 742753
This is an intentional change from the design in bug 880735. Our user research study showed that most users are confused by per-element clicktoplay. We encourage users who want that level of control to use adblock/flashblock or a similar addon which implements that kind of per-element control.
Alias: CTP-perelement
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> This is an intentional change from the design in bug 880735. Our user
> research study showed that most users are confused by per-element
> clicktoplay. We encourage users who want that level of control to use
> adblock/flashblock or a similar addon which implements that kind of
> per-element control.

I'm saying this regression includes some security security issue, not only usability. Some attack model injects malware code which uses vulnerability for their attacking. In this case, it's easy that user invoke malwares by accident because the browser invoke all plugins by Click-to-play. This cannot protects users from mal-attack. (I memory that we have discussed about it in bug 742753 when we had implemented the previous click-to-play.)


adblock/flashblock or a similar addon don't provide same features. For example, Flashblock replaces element with using XBL binding. So its implementation has a little lags. Thus they need to invoke plugins small amount of time. This cannot protect above security problem. Are there some API which provide the hooking for their addons?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
And from usability, I remember click-to-play is opt-in features. So we can assume users who uses click-to-play knows or have some drive to know that how click-to-play works. Therefore I think we can take the way to guide their to the SUMO docs which accounts click-to-play.
Could you tell me about why we cannot take help docs or tooltips to help users?
Please don't reopen this bug. The click to play UI is primarily intended to be for

1) users opting in to use new plugins so that they are not automatically enabled on their system
2) unsafe/vulnerable plugins where we want to minimize user risk or encourage users to upgrade

Neither of these cases is served by per-element click to play, and it will be pretty simple for addons to continue implementing per-element behavior for users who understand what that means.

Further discussion can be initiated on the dev-firefox mailing list: https://mail.mozilla.org/listinfo/firefox-dev
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → WONTFIX
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> 1) users opting in to use new plugins so that they are not automatically
> enabled on their system

I think this feature is not only to use new plugins but also user control whether playing plugins if user turn on "plugins.click_to_play". In such case, the important thing is that user are able to control to play plugins.


> 2) unsafe/vulnerable plugins where we want to minimize user risk or
> encourage users to upgrade

In this point I explained in comment #2, 1) Some attack model inject malware which uses the vulnerability of plugins to normal pages. 2) Their attack model recommends enabling the plugins having vulnerability to user. 3) Click-to-play once at all model is very weak if user activate normal plugins which include the vulnerability on the page which is injected malware.

> Neither of these cases is served by per-element click to play, and it will
> be pretty simple for addons to continue implementing per-element behavior
> for users who understand what that means.

In the case which user turn on "plugins.click_to_play" on about:config, I think we can say same things. They would understand what that means.
Can we at least get an option in about:config. This is a very annoying change for me.
Indeed, i don't see why we can't have both the doorhanger and selective activation as it was before or even an option to choose between the two.

At the moment it feels like the windows UAC - an annoying prompt which doesn't help at all.
Indeed, it is intrusive and adds an extra click + dialogue box read to simply allow the flash instance you wish too. 

There is also a bug with this new method when you open multiple tabs from one site. If you allow plugins in one tab, then in other tabs when you click to activate a plugin instance you are prompted to "keep allowing" or "block", but clicking "keep allowing" does not activate the plugins in that tab. You actually have to reload the tab to activate the plugins.

Also of note is that Chrome does click to play per plugin instance, like Firefox used to.
I have filed bug 887088 about the bug from comment 9. Please take general discussion to the thread that saneyuki_s started in dev-firefox.
And furthermore, it is impossible to disable this now bastardized CTP if someone has Flashblock enabled.

I disabled CTP so I could use Flashblock instead, but CTP keeps taking over.
Depends on: 888705
If bug 902535 is a dup of this one: then this one needs to be reopened and locked against wontfix until someone who has two braincells to rub together fixes this mess.

This is a performance bug, a security bug, a usability bug, and a parity bug. You cannot get worse than the current state of affairs we are in.
If you're missing the previous behavior, check out the addon from comment 12.
That might work for me but I'm more concerned with the rest of the Firefox userbase. The ones that don't understand how the feature works and are going to be very unhappy with it once they start using it. Either because they wind up compromised or because the UX is just so terrible and unintuitive.
(In reply to Cam from comment #16)
> That might work for me but I'm more concerned with the rest of the Firefox
> userbase. The ones that don't understand how the feature works and are going
> to be very unhappy with it once they start using it. Either because they
> wind up compromised or because the UX is just so terrible and unintuitive.

We found the opposite when doing user research on this - most users don't understand plugins, or elements on a page, and were confused by the functionality. This method is is much more straightforward, allowing users to allow the plugin for a specific page once or forever. Power users are likely to have different needs, and I opened bug 902650 to make it easier for simple addons to tweak this behavior as desired.
Is it impossible to have both features implemented at the same time?

The add-on doesn't seem to be interfering with the doorhanger in any way.

I am glad that you are allowing extensions to tweak and enable additional features but i just can't understand why such a basic feature isn't included in firefox by default.
It's not impossible to do both, but given the additional code- and testing-complexity and the relatively small user group this affects it is not sensible.
Add-ons should be the best solution here, especially with different add-ons covering slightly different needs.

Further discussions would be best had on the firefox-dev mailing list [1] though, where the re-design of the feature was already discussed, e.g. in [2].

[1] https://wiki.mozilla.org/Firefox/firefox-dev
[2] https://mail.mozilla.org/pipermail/firefox-dev/2013-June/000460.html
(In reply to Georg Fritzsche [:gfritzsche] from comment #20)
> It's not impossible to do both, but given the additional code- and
> testing-complexity and the relatively small user group this affects it is
> not sensible.

The testing was not complex.
https://hg.mozilla.org/mozilla-central/file/999f162be482/browser/base/content/test/browser_pluginnotification.js
It is such an ugly change to this wonderful feature.
In case someone of Firefox developers are reading this comments here is my suggestion for "returning 23.0 style" without additional addons:

First, thank you for having this option

plugin.sessionPermissionNow.intervalInMinutes

which when set to '0' blocks loading video in new opened YT tabs.



In future versions you could also add something like:

plugin.activateAllElementsOnPage 

where if it is set to false it will activate only one element and not all.
In other words, just add in old code one more option which will activate all "plugin elements" on page (not only one) like it is in 24.0 and give us option in about:config to change it to "activate only one plugin element on page".

Regards.
I can't understand the reasoning for this regression.
Yeah, I've seen that "research" PDF with average users not understanding CTP.
But here's the thing:
The average user doesn't go to about:config tweaking settings. Never has, never will. 
He/she simply has plugins enabled without using CTP.

So why exactly was this changed for those who actually use this feature?
Where was the problem?
Why do I have to install yet another addon for functionality that is included out of the box in decent browsers and was included in Firefox for years without causing any problems?
(In reply to ponoboy from comment #25)
> The average user doesn't go to about:config tweaking settings. Never has,
> never will. 
> He/she simply has plugins enabled without using CTP.

Plugins are becoming click-to-play per default in Firefox 26 (except Flash for now), see bug 899080.
I see. And that's a good move.

Still, I don't see the need to do away with existing functionality and force us to install an add-on (unless we want to be bombarded with all kinds of plugin elements on a website).

Having to install 3rd party add-ons is bad from both a security and usability perspective.
As my bug 918730 was marked as a duplicate of this one, I want to post my suggestion here to:

Offer a different choice. In the doorhanger ask: “Allow example.com to run ‘Example plugin’?”
But then offer the options “only clicked element” and “all elements” (the last one as standard). Below the question there should be a checkbox “Decide again in XX Minutes” (checked; depends on the setting plugin.sessionPermissionNow.intervalInMinutes in about:config).

[This idea isn’t sufficient because you still have to decide on every domain.]

As the behaviour is implemented now, you annoy “old” users who miss the fine control they had and also “new” users who didn’t decide to use CTP at all. Both have to click twice on every domain to play the content – and then all the malicious elements are unblocked, too (yeah, in the best case just for an hour).

Question: Why shall flash be excepted from click to play? Because the implementation as it is only doesn’t suck if you block seldom used plugins? Are you planning any changes until FF26?

Suggestion 2: Restore CTP as it was. Instead set every plugin to inactive. Then, if a website wants to use it, blend in a doorhanger were you ask if and how long the plugin should be activated for this domain. Sounds like the recent behaviour? Yes, but that’s not click to play, but whitelist this plugin for a certain domain. Don’t mix this up. It has to be implemented in another way.
(In reply to ponoboy from comment #25)
> I can't understand the reasoning for this regression.
> Yeah, I've seen that "research" PDF with average users not understanding CTP.
> But here's the thing:
> The average user doesn't go to about:config tweaking settings. Never has,
> never will. 
> He/she simply has plugins enabled without using CTP.
> 
> So why exactly was this changed for those who actually use this feature?
> Where was the problem?
> Why do I have to install yet another addon for functionality that is
> included out of the box in decent browsers and was included in Firefox for
> years without causing any problems?

Also, it's not the first time they messed around with ClicktoPlay,
on v 23 IIRC, you had to go to the addons plugin tab and select "ask to activate"
on top of going to about:config and setting "ClicktoPlay" to "TRUE",
which at the time I thought was ridiculous. and now this counterproductive fudging,
I'm at a loss for words.

it seems that every FF update you need to go through more and more steps to get CtP to work properly.
I read somewhere Mozilla is bought and controlled by Google.
seems logical now,
either Youtube wants to take away video watching controls,
or
it's some kind of planned-obsolescence, to push people onto Chrome.

regression no doubt!
Hey Mozilla, don't take too much of us for novices.
I was really enthusiast about the old Click-to-play : it was safe, it worked for all plugins, and showed clearly which element needed what. We could allowed this or that selectively.
If users are confused about Click-to-play, then it's your damn fault for not having implemented a good enough UI.
Offer different choices is the best choice!
Seriously Mozilla... Are you mad?

Could you please stop favoring the morons, just for once? If even CTP is too "complicated" for what seems to be the majority of your users, perhaps those idiots should consider selling their computer and go live in their cave again, bang some rocks together maybe.

Everything you've done lately is an insult and serious inconvenience to more savvy people, whom, IMHO, are more deserving of being favored instead of disadvantaged than idiots.

Also, the fancy add-ons you suggest to use to fix this? First off, they don't work anymore. Secondly, every add-on you need to fix a given feature increases the likelihood of not being able to update due to the add-on also having to update as well as the likelihood of the feature not being available anymore at some point (dev quits). Thirdly, CTP per-element is NOT a strain on your workload in any way. If even that is too much work for you, perhaps you should find some better programmers.

Also, labeling all savvy people as "minor use cases" and then completely ignoring them is bound to lead to your doom. Firefox will become a product for idiots.
(In reply to Georg Fritzsche [:gfritzsche] from comment #20)
> It's not impossible to do both, but given the additional code- and
> testing-complexity and the relatively small user group this affects it is
> not sensible.
> Add-ons should be the best solution here, especially with different add-ons
> covering slightly different needs.
> 
> Further discussions would be best had on the firefox-dev mailing list [1]
> though, where the re-design of the feature was already discussed, e.g. in
> [2].
> 
> [1] https://wiki.mozilla.org/Firefox/firefox-dev
> [2] https://mail.mozilla.org/pipermail/firefox-dev/2013-June/000460.html

Also, where do you keep getting those poll results from anyway? I've never been asked a damn thing in all the years I've used Firefox. The only people you seem to ask those questions to are the exact people you shouldn't be asking at all.
Blocks: click-to-play
I strongly feel that per-page is absolutely the wrong way to do it. 

http://www.washingtonpost.com/blogs/the-switch/wp/2014/01/04/thousands-of-visitors-to-yahoo-com-hit-with-malware-attack-researchers-say/

Put yourself in the position of someone who trusts Yahoo's Java and is content to click on the big panel in the middle of the page where the game normally goes. There's ads around the edge but they are almost always harmless animated GIFs at the most.

One day, a malicious ad finds its way oto the page. The user, intending only to run the main app on the page, clicks the to run it. With per-element, the malicious ad doesn't run. With per-page, everything runs.

But what are we getting for this trade-off? In a per-element world, the user sees a big panel on the page with a play button. The user clicks it and only that thing is played. The other stuff hiding around the edges doesn't run. If you're putting up a website and you want the reader to play some flash/java/etc, stick it upfront. I've no interest in rewarding people who hide their flash content around the edges or in the hidden areas of a page. That stuff SHOULDN'T be run!

Per-element is:
A. More secure, as it reduces the oportunities for a malicious object to run.
B. Simple. There's a play button, click it and it runs.
C. Better user experience, as the play button doesn't cause anything else to start unexpectantly.
D. Encourages better design. We want flash content to be put into a panel, not hidden away.

Click-to-play was a relief from the panic of having to reinstall flash every few weeks and not being able to use the internet until then. Since we can't really rely on third-party advertisers to stop malicious flash from turning up, we're back into the panic of having to update the flash player or just having to always say "No, I won't let the flah run, even though I've no problems running that one embedded YouTube video.".

And please don't recommend some add-on. I've run add-ons in the past and they will often stop working because the browser has just been updated or something. 

Please reconsider this decision.
(In reply to Bill P. Godfrey from comment #41)

> I strongly feel that per-page is absolutely the wrong way to do it. 

Anyway, I think that, with the good old click-to-play per element, allowing Flash for the whole page is still possible, by clicking a button at the left of the address bar.

> A. More secure, as it reduces the oportunities for a malicious object to run.
> B. Simple. There's a play button, click it and it runs.
> C. Better user experience, as the play button doesn't cause anything else to
> start unexpectantly.
> D. Encourages better design. We want flash content to be put into a panel,
> not hidden away.

> Please reconsider this decision.

I agree with Bill.

And click-to-play per page is not only insecure, in some pages it is also unusable. 
On Dailymotion, sometimes, when I click-to-play the video, the video starts playing… but the ad video on the right starts playing too ! At the same time, and with the sound ! So there is a cacophony. 
In some cases, the ad video is a little more decent, it plays but without bringing the parasite sound. Even in these cases, this still disturbs me. 
And this has another impact : this uses resources. 
This makes my Mac lag, and blow a lot (this is Flash !). And this empties my battery (this is Flash !). This uses my electricity. This costs me money. And this is bad for the planet Earth.
Discussions about this feature and it's design should go to the firefox-dev mailing list:
https://wiki.mozilla.org/Firefox/firefox-dev
I agree with Nicolas, it's very serious regression from security point of view. It should be fixed as soon as possible.
Just wanted to notify this Bug that Georg Fritzsche has direct us to the firefox-dev mailing list, but so far my submissions have been dropped for no reason. I have been polite and very concerned about this usability change and so far haven't had much success in getting the list to acknowledge this fact.
Forgot to post my bug report since the list is not accepting it for some reason:

I appreciate the ton of work you guys do, but forgive me for saying I think removing the click to play per element feature is a backward step in security. I know you say that its too confusing for people. But humbly speaking that was an option within the about:config settings. Nobody even uses those settings to make changes to their browser except people who know what they are doing.


Can you please add that feature back. There are reports now that two security firms are selling tech to law enforcement that allows them to legally own a system though a youtube video. I dont want firefox development to get a bad reputation of deliberately removing security features that are meant to protect your users.

I know there is a plug-in that restore that feature, but I have seen plugs get disabled without the users control before so that avenue is red herring.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.