Closed Bug 887088 Opened 11 years ago Closed 3 years ago

Click to play UI is confusing when you allow on one tab

Categories

(Core Graveyard :: Plug-ins, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX
mozilla24

People

(Reporter: benjamin, Unassigned)

References

Details

STR: * Mark Flash as click-to-activate * Open more than one tab to http://benjamin.smedbergs.us/tests/ctptests/flash-solo.html * In one of the tabs, choose to activate Java * Switch to another tab and click the in-page UI Actual Results: * The doorhanger opens and says "'Adobe Flash' is enabled on benjamin.smedbergs.us" / Block Plugin / Continue Allowing * Clicking "Continue Allowing" does nothing Expected Results: I'm not sure what the best behavior is here. We could try to activate affected plugins in all tabs when the permissions change, although the implementation of that might be somewhat complex and probably not branch-worthy. We could also at least make "Continue Allowing" activate any relevant plugins on the current page. This seems like a minimally invasive change. There may also be the possibility of something intermediate like activating plugins when we switch back to this tab, but that's also a bit tricky. lco, thoughts?
Flags: needinfo?(lco)
OS: Linux → All
Hardware: x86_64 → All
* The doorhanger opens and says "'Adobe Flash' is enabled on benjamin.smedbergs.us" / Block Plugin / Continue Allowing * Clicking "Continue Allowing" does nothing This is the same box that I'm getting with every video though "click to play" is disabled: "Block Plugin / Continue Allowing" with several addons installed. If they're disabled then there's no box. The Autohide extension is one. Will it be up to the developers to fix this bug as a result of the changed feature? No doubt there may be other addons affected that we just haven't heard about yet and to be honest it is somewhat annoying.
(In reply to Marty from comment #1) > * The doorhanger opens and says "'Adobe Flash' is enabled on > benjamin.smedbergs.us" / Block Plugin / Continue Allowing > * Clicking "Continue Allowing" does nothing > > This is the same box that I'm getting with every video though "click to > play" is disabled: "Block Plugin / Continue Allowing" with several addons > installed. If they're disabled then there's no box. The Autohide extension > is one. Will it be up to the developers to fix this bug as a result of the > changed feature? No doubt there may be other addons affected that we just > haven't heard about yet and to be honest it is somewhat annoying. Can you please file a separate bug about this which includes the addons you have installed, the page that you're on, and steps to reproduce so that we can explore this issue further? This bug is about a particular edge case wherein the same tab is opened twice. Thanks!
Flags: needinfo?(lco)
That can be done and will be done if needed however since it's the same exact box wording (there are several) I figured that this bug and the one I'm experiencing may be related. It's occurring on any site where Flash is loaded.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #0) > Actual Results: > * The doorhanger opens and says "'Adobe Flash' is enabled on benjamin.smedbergs.us" / Block Plugin / Continue Allowing > * Clicking "Continue Allowing" does nothing This one's tricky. Does this also apply to tabs in the same site domain (not just if you open the same tab twice)? For example, if I have two tabs open: site.com/flash-1 and site.com/flash-2, and I enable plugins on site.com/flash-1, will we get the same bug when I go to site.com/flash-2? I'm asking this because I believe we're enabling the plugin per domain (not per page), so this might affect my assumptions of how many people this bug might affect. > Expected Results: > I'm not sure what the best behavior is here. We could try to activate > affected plugins in all tabs when the permissions change, although the > implementation of that might be somewhat complex and probably not > branch-worthy. > If I take a step back and think about what the user expects, then I'd say: "If I enabled the plugin on one tab, then I expect it to be enabled on others automatically". In theory, we shouldn't have to make the user do any more work than he needs to. So this is the solution I prefer. However, I don't know how difficult it would be to actually detect that the plugin state has changed and then automatically refresh other pages on the site with the same plugin. In which case, see my last comment below... > We could also at least make "Continue Allowing" activate any relevant > plugins on the current page. This seems like a minimally invasive change. This is my least preferred solution because it makes the user do more work and it's quite confusing as it is, even if we activate the button. > > There may also be the possibility of something intermediate like activating > plugins when we switch back to this tab, but that's also a bit tricky. > By this, you mean that the plugin refreshes when the tab is on focus? I think that's an acceptable solution. > lco, thoughts? I'll think about this a little more, but it seems like the solutions you proposed are the sames ones I can think about. If your second idea (make the button work to update the plugin on page) is the quickest choice for now, then we should do it. But I don't want that to be the permanent solution.
> This one's tricky. Does this also apply to tabs in the same site domain (not > just if you open the same tab twice)? Yes.
A patch for the short-term solution is now in bug 889788. I'll clone this when that lands to track a better long-term solution.
> If I take a step back and think about what the user expects, then I'd say: "If I enabled the plugin on one tab, then I expect it to be enabled on others automatically". In theory, we shouldn't have to make the user do any more work than he needs to. I find the behaviour in ff25 (and maybe 24, i skipped that one) very annoying (allowing on all tabs just because i activate on one tab). I have click to play enabled because i _don't_ want plugins to activate by default. Now i have to explicitly re-disable plugins before closing a tab in order for them to not load on new tabs. Could I have an option back to make click to play only play, and not change default settings(temporarily)? Preferably without also requiring a second click on the doorhanger, and just play the thing.
(In reply to Mikael Magnusson from comment #7) > Could I have an option back to make click to play only play, and not change > default settings(temporarily)? Preferably without also requiring a second > click on the doorhanger, and just play the thing. Maybe this addon suits your usage better: https://addons.mozilla.org/de/firefox/addon/click-to-play-per-element/ Alternatively, you could set the pref plugin.sessionPermissionNow.intervalInMinutes to 0.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #6) > A patch for the short-term solution is now in bug 889788. I'll clone this > when that lands to track a better long-term solution. Do we already have this filed somewhere?
Flags: needinfo?(benjamin)
(In reply to Larissa Co [:lco] from comment #4) > If I take a step back and think about what the user expects, then I'd say: > "If I enabled the plugin on one tab, then I expect it to be enabled on > others automatically". That assumption is very discussable. As a user, when I tell Firefox do do some thing for a tab, I do not expect it to repeat the action elsewhere.
(In reply to Nicolas Barbulesco from comment #10) > (In reply to Larissa Co [:lco] from comment #4) > > > If I take a step back and think about what the user expects, then I'd say: > > "If I enabled the plugin on one tab, then I expect it to be enabled on > > others automatically". > > That assumption is very discussable. As a user, when I tell Firefox do do > some thing for a tab, I do not expect it to repeat the action elsewhere. I want to clarify that we aren't trying to enable CtP on ALL your tabs if you enable it in one tab. Rather, this bug refers to two limited cases: 1. you have multiple tabs open pointing to the same URL 2. you have multiple tabs open that have the same domain The first case is more clear cut: if it's the same page, you'd expect the plugin permissions to be the same. In the second case, we decided to make CtP support per domain to reduce interruptions for users who are engaged on plugin-heavy sites. For example, if I want to watch 5 YouTube videos in a row, I don't necessarily want to click a doorhanger to enable each one. A regular user perceives trust as something that is granted to the site as a whole, not to an individual plugin; thus per-domain CtP matches their mental model. (I know there are subtleties, for example, in the case of ads, the source of the plugin might not be the same in every page in the domain etc., but hopefully this can be addressed in a future iteration.)
(In reply to Larissa Co [:lco] from comment #11) > > That assumption is very discussable. As a user, when I tell Firefox do do > > some thing for a tab, I do not expect it to repeat the action elsewhere. > In the second case, we decided to make CtP support per domain to reduce > interruptions for users who are engaged on plugin-heavy sites. For example, > if I want to watch 5 YouTube videos in a row, I don't necessarily want to > click a doorhanger to enable each one. I can understand this expectation, although I disagree with it. We can keep this behaviour you expect AND have the following behaviour I expect. I am listening to my YouTube video, and at the right there are links to other videos. I middle-click them. They open in background tabs. BUT they all start playing at the same time, giving a cacophony. So I go stop them one by one, and I go back to my first tab. This is what I call a user interruption. Instead, I naturally expect that the videos not play until I click them (like in Chrome and in previous Firefox). We can keep your behaviour for the same tab and apply click-to-play for the other tabs.
(In reply to Nicolas Barbulesco from comment #12) > I am listening to my YouTube video, and at the right there are links to > other videos. I middle-click them. They open in background tabs. BUT they > all start playing at the same time, giving a cacophony. So I go stop them > one by one, and I go back to my first tab. This is what I call a user > interruption. Instead, I naturally expect that the videos not play until I > click them (like in Chrome and in previous Firefox). This specific case is not really in the scope of Firefox click-to-play, you might be better served by a specialized addon like "click-to-play per element": https://addons.mozilla.org/en-US/firefox/addon/click-to-play-per-element/
(In reply to Larissa Co [:lco] from comment #11) > (In reply to Nicolas Barbulesco from comment #10) > > (In reply to Larissa Co [:lco] from comment #4) > > > > > If I take a step back and think about what the user expects, then I'd say: > > > "If I enabled the plugin on one tab, then I expect it to be enabled on > > > others automatically". > > > > That assumption is very discussable. As a user, when I tell Firefox do do > > some thing for a tab, I do not expect it to repeat the action elsewhere. > > I want to clarify that we aren't trying to enable CtP on ALL your tabs if > you enable it in one tab. Rather, this bug refers to two limited cases: > > 1. you have multiple tabs open pointing to the same URL > 2. you have multiple tabs open that have the same domain > > The first case is more clear cut: if it's the same page, you'd expect the > plugin permissions to be the same. > > In the second case, we decided to make CtP support per domain to reduce > interruptions for users who are engaged on plugin-heavy sites. For example, > if I want to watch 5 YouTube videos in a row, I don't necessarily want to > click a doorhanger to enable each one. A regular user perceives trust as > something that is granted to the site as a whole, not to an individual > plugin; thus per-domain CtP matches their mental model. (I know there are > subtleties, for example, in the case of ads, the source of the plugin might > not be the same in every page in the domain etc., but hopefully this can be > addressed in a future iteration.) I'd like to offer the opposite point of view, not from abstract thinking, but from my own day-to-tay practice. I mistrust plugins in general, and by default I leave click-to-play set and I don't do the "enabler" click in the placeholders. For PDF I use the PDF-JS extension (thus bypassing the Adobe plugin) or, in the case of PDF files which PDF-JS cannot display satisfactorily, I open them in an external Acrobat Reader application. When I exceptionally want to "play" one particular plugin, I click the placeholder (or, of there weren't one, I would click the button in the doorhanger or notification-bar), but I don't want all plugins in other tabs for the same site (and possibly for the same page) to suddenly get enabled together, producing a cacophony if they are plugins "with sound" but with different soundtracks (for instance, I have several YouTube tabs: I shudder at the mere thought of hearing them all at the same time).
Didn't need to clone this since it's still open. The solution we should implement is to auto-activate plugins in other tabs when we switch to them. This is not high priority, however. Use cases such as comment 14 are not the primary design goal and should be solved using addons (either the per-element CTP addon or more complicated things such as adblock/flashblock).
Assignee: benjamin → nobody
Flags: needinfo?(benjamin)
Priority: P2 → P3
No assignee, updating the status.
Status: ASSIGNED → NEW
No assignee, updating the status.
Resolving as wont fix, plugin support deprecated in Firefox 85.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.