It is currently not possible to disable plugins in the web runtime. Choosing to disable a plugin in Desktop Firefox will not correspondingly disable the plugin the desktop runtime - This is likely expected, given that the two entities should act independently. However, given that the two entities are independent implies that a user should be allowed to control their plugins within the web runtime. Here's an example of a test case involving the Java plugin: http://mozqa.com/data/firefox/popups/javaclock/index.html. Going to that page with Java enabled shows the clock in desktop firefox and the web runtime. Going to that page with Java disabled shows the clock in desktop firefox, but not the web runtime. We need a resolution to allow the user to control their plugins within the web runtime.

Needs assistance from product management team. Open question - What should we do for plugin management for the first release of desktop WebRT? What should be done going into the future?

Note - Flash is a P1 requirement for the desktop webRT. Also, there are old versions of flash that are blocklisted, so we'll need to have the ability to test that.

Flash is the only plugin in the scope for the desktop runtime. All others will be implicitly disabled. This implementation needs to make sure that a user has the ability to disable flash within the desktop runtime.

Unsure about k9o blocking. A few thoughts / Qs: * Does blocklisting still work? Could be important for Flash crashers / vulnerabilities. Input from security would be helpful. * OTOH if a install a webapp implies a higher level of trust (or at least limiting usage to essentially 1 site), then it's less of an issue (vs browsing the web in general). * User-control, specifically, seems even less important. Either the apps needs flash or it doesn't, and you ultimately have the option to uninstall it. AIUI we're not exposing the addon manager UI anywhere, so that makes the implementation of this rather difficult. * Not sure of the details around apps/plugins in general -- do webapps have _no_ ability to opt-in to using, say, Java? Is there a mechanism for them to optin/optout of Flash?

Based on my understanding of the runtime's product vision and requirements, we should not fix this, given that the runtime will only be supporting the Flash plugin, and (as dolske notes) user control over that plugin for the runtime as a whole seems less important than it is in a browser, since many apps that use Flash will need it, in which case there's no point disabling it; you might as well just uninstall the app. There may be some apps that use Flash but don't need it, and some users might want to disable Flash for those apps, so I can imagine a use case for a feature that enabled users to disable Flash for particular apps. But that is speculative and theoretical at this point, so it isn't worth having an open bug on file for it. Thus I'm resolving this wontfix and cancelling various flags for getting people to pay attention to this bug. But ticachica, the product owner for the runtime, is cc:ed to the bug, and she is welcome to reopen it if she disagrees.

(In reply to Justin Dolske [:Dolske] from comment #4) > Unsure about k9o blocking. A few thoughts / Qs: > > * Does blocklisting still work? Could be important for Flash crashers / > vulnerabilities. Input from security would be helpful. I'm digging into this on two separate bugs - bug 754080 and bug 755557. > > * OTOH if a install a webapp implies a higher level of trust (or at least > limiting usage to essentially 1 site), then it's less of an issue (vs > browsing the web in general). > > * User-control, specifically, seems even less important. Either the apps > needs flash or it doesn't, and you ultimately have the option to uninstall > it. AIUI we're not exposing the addon manager UI anywhere, so that makes the > implementation of this rather difficult. We might want to look at the negative use cases. What's the original intention for even having disable plugins in firefox then? Trying to better understand the connection to what value (if anything) it could hold in the web runtime. Note for implementation - we could follow a shared policy for simplicity (disable in firefox = disable in web runtime). That make the implementation easier - it makes sense also (it's a global disable). > > * Not sure of the details around apps/plugins in general -- do webapps have > _no_ ability to opt-in to using, say, Java? Is there a mechanism for them to > optin/optout of Flash? The only plugin allowed to run in the web runtime is flash (nothing else in there) - see bug 755554. It's not possible for a user to opt-in or opt-out of flash right now in the web runtime (that's actually what this bug intends to do). Opting out of flash (aka disable) in desktop firefox also would not have an effect on the desktop runtime whether flash runs or not (already tested this). If a user wanted to not run flash in the desktop runtime, then they would have to completely uninstall it from their machine. (In reply to Myk Melez [:myk] [@mykmelez] from comment #5) > Based on my understanding of the runtime's product vision and requirements, > we should not fix this, given that the runtime will only be supporting the > Flash plugin, and (as dolske notes) user control over that plugin for the > runtime as a whole seems less important than it is in a browser, since many > apps that use Flash will need it, in which case there's no point disabling > it; you might as well just uninstall the app. Not sure I agree entirely with the rationale given here, but I think it would be worth thinking about negative use cases here. Plugins in firefox are a very problematic area on the testing side (example scenario described today - Firefox user updates to a new version of flash, and boom! Crashes firefox at a significant rate). The negative use case to be thought about if say, I updated to a new version of flash that caused firefox users a lot of problems within the web runtime, but maybe not other browsers (Chrome). Felipe also described a use case involving safe mode to disable plugins, but that might be separate from this bug. Juan, Anthony, and Marcia - Could you provide insight here, since all of you are experienced with plugin problems in firefox? > > There may be some apps that use Flash but don't need it, and some users > might want to disable Flash for those apps, so I can imagine a use case for > a feature that enabled users to disable Flash for particular apps. But that > is speculative and theoretical at this point, so it isn't worth having an > open bug on file for it. See the above negative use cases for a rationale (we might want to analyze it to be sure). > > Thus I'm resolving this wontfix and cancelling various flags for getting > people to pay attention to this bug. But ticachica, the product owner for > the runtime, is cc:ed to the bug, and she is welcome to reopen it if she > disagrees. Actually, the right people to probably determine if this is a won't fix or not is probably not us (Bill, me, you, Jen). It's probably someone experienced in plugin development, problems, and testing. Josh - Could you provide insight here?

(In reply to Jason Smith [:jsmith] from comment #6) > Juan, Anthony, and Marcia - Could you provide insight here, since all of you > are experienced with plugin problems in firefox? Jason, here is my personal point of view, as someone who has dealt with plug-ins testing in Firefox Desktop for a couple of years. At a very high level, the cases you want to test for *any* plug-in are: * installing the latest * updating from an old version * blocklisting * opting out of a blocklist * updating after being blocklisted * manually enable/disable * safe-mode * uninstall On the desktop side of things, there are two ways Flash can be disabled: 1) Manually by the user, ie. they decide for whatever reason they don't want Flash running at that time 2) Blocklisted by Mozilla, ie. we decide it's causing too many stability/security concerns In either scenario, the disable is global (it disables Flash for all websites). In other words, we don't have a per-website plugin policy. One could argue we should be able to do the same within the Runtime. I would personally be worried if we have no facility to allow disabling of plugins in the runtime, whether through user action or blocklist. The open question is if we should give users the granular control to disable Flash on a per-App basis. We don't allow users to do this on a per-website basis (for whatever reason) so I'm not sure why we would allow it on a per-app basis. In summary (my personal opinion): * Disabling/Blocklisting a plug-in in the Runtime should be a scoped usecase * Disabling a plug-in for a specific App should probably not be a scoped usecase I'm happy to answer any follow-up questions.

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #7) > (In reply to Jason Smith [:jsmith] from comment #6) > > Juan, Anthony, and Marcia - Could you provide insight here, since all of you > > are experienced with plugin problems in firefox? > > Jason, here is my personal point of view, as someone who has dealt with > plug-ins testing in Firefox Desktop for a couple of years. > > At a very high level, the cases you want to test for *any* plug-in are: > * installing the latest > * updating from an old version > * blocklisting > * opting out of a blocklist > * updating after being blocklisted > * manually enable/disable > * safe-mode > * uninstall > > On the desktop side of things, there are two ways Flash can be disabled: > 1) Manually by the user, ie. they decide for whatever reason they don't want > Flash running at that time > 2) Blocklisted by Mozilla, ie. we decide it's causing too many > stability/security concerns > > In either scenario, the disable is global (it disables Flash for all > websites). In other words, we don't have a per-website plugin policy. > > One could argue we should be able to do the same within the Runtime. I would > personally be worried if we have no facility to allow disabling of plugins > in the runtime, whether through user action or blocklist. > > The open question is if we should give users the granular control to disable > Flash on a per-App basis. We don't allow users to do this on a per-website > basis (for whatever reason) so I'm not sure why we would allow it on a > per-app basis. > > In summary (my personal opinion): > * Disabling/Blocklisting a plug-in in the Runtime should be a scoped usecase > * Disabling a plug-in for a specific App should probably not be a scoped > usecase > > I'm happy to answer any follow-up questions. Hmm okay. I agree with your rationale. Per app basis doesn't make sense, but a global disable might actually make sense in this case. For implementation simplicity, we could just do a global disable across firefox and the runtime (I disable flash in firefox, it correspondingly disables flash in the runtime). I don't think that would be hard to implement, but someone from engineering could clarify that. Unless there's really strong reason why this is out of scope, I just don't see a reason to won't fix this. Reopening.

Opinion on Priority and Milestone: Priority: P1, non-blocker Milestone: Firefox 15 Reasoning: This a basic piece of functionality supported when using plugins (e.g. flash). Not implementing this runs the risk of the problems that come with plugins with specific firefox versions - you won't be able to temporarily take control of the situation unless you uninstall flash from the underlying system. A simple solution is stated in above comments - could be as simple as just supporting a global disable, even if it's done through firefox (unless there's a reason to have the two be separate).

Global disable seems to make sense though it'd have to be a separate pref (with UX) as plugin disabling is a per profile setting. (I disable flash in profileA in Nightly, its still enabled in profileB - if disabling in profileA also disables app flash then how is that represented in profileB?)

Jen and I talked through this request today and concluded that it remains wontfix. It isn't sufficient justification that the feature exists for content in Firefox, since the runtime is a distinct presentation of web content whose featureset is not arbitrarily consistent with the browser's. So far we haven't identified a specific usecase for this feature. And Anthony's concern about having "no facility to allow disabling of plugins in the runtime, whether through user action or blocklist" is satisfied by the blocklist facility we've built into the runtime. If we identify a specific usecase in the future, then we can reopen this bug. Or, better yet, discuss the usecase in the discussion forum, come to some conclusion about how to address it, and then file a new bug to do that specific thing. And remember to keep an open mind, as the solution might involve a global setting, but it might involve a per-app setting or some completely different functionality.