768521 - Soft-blocking pop-up window appears in the runtime when soft-block is specified - no pop-up should appear

Status: RESOLVED FIXED

(Firefox Graveyard :: Webapp Runtime, defect, P2)

Description

[Andrew Williamson [:eviljeff]]

Attachment: screenshot of block dialog

If you have a plugin that's on the blocklist, (Java SE6 U29 in my case) then the block dialog pops up in the app after a short while.   

This seems to happen for every app while, as a I understand it, the plugin shouldn't be available anyway.

Comment 1

[Jason Smith [:jsmith]]

(In reply to Andrew Williamson [:eviljeff] from comment #0)
> Created attachment 636762 [details]
> screenshot of block dialog
> 
> If you have a plugin that's on the blocklist, (Java SE6 U29 in my case) then
> the block dialog pops up in the app after a short while.   
> 
> This seems to happen for every app while, as a I understand it, the plugin
> shouldn't be available anyway.

Isn't this expected behavior for the blocklist?

We're doing blocks on a per app basis (each app has it's own blocklist), which is likely why you are getting the prompt for every single app. Should we do a one-time only prompt for the runtime as a whole? Manage the blocklist on the runtime at a high-level, instead of a per-app basis?

Comment 2

[Andrew Williamson [:eviljeff]]

I'm not sure the best solution on the blocklist being per app or per runtime - I'd favour one per runtime.  

But in this case its more that in bug 755554 its specified that only Flash will be available in the runtime but we're asking the user if they want to block Java instead.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Andrew Williamson [:eviljeff] from comment #2)
> I'm not sure the best solution on the blocklist being per app or per runtime
> - I'd favour one per runtime.  

I'll change the title to reflect that then.

> 
> But in this case its more that in bug 755554 its specified that only Flash
> will be available in the runtime but we're asking the user if they want to
> block Java instead.

That's a separate bug - we're planning disabling all plugins except flash in the runtime. See bug 755554.

Comment 4

[Jason Smith [:jsmith]]

Switching the bug back to its original intention per today's discussion - the soft-block UI should not be coming up at all in the runtime, as there's no concept of soft-blocking plugins in the desktop runtime.

Comment 5

[Jason Smith [:jsmith]]

Alex or Jorge - How often have we soft-blocked flash? We're trying to figure out how often this bug could occur in the web runtime in order to prioritize this bug.

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

We soft-blocked some old versions of Flash a few months ago, and we considered doing a similar thing more recently (and didn't in the end). Flash is so prevalent that any kind of block is a massive and disruptive action, so we do it very sparingly.

Comment 7

[Marco Castelluccio [:marco]]

Why the popup shouldn't appear? Should we disable without telling the user?

Comment 8

[Myk Melez [:myk] [@mykmelez]]

(In reply to Marco Castelluccio [:marco] from comment #7)
> Why the popup shouldn't appear? Should we disable without telling the user?

As jsmith notes in comment 4, there's no concept of soft-blocking plugins in the runtime.  A plugin is either blocked or it isn't.

Also note that most plugins are disabled by default anyway, so blocking only matters for the (single) plugin that isn't disabled (Flash).

Comment 10

[Myk Melez [:myk] [@mykmelez]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #8)
> Also note that most plugins are disabled by default anyway, so blocking only
> matters for the (single) plugin that isn't disabled (Flash).

In bug 1122780, \n saw this dialog for Silverlight, so perhaps this doesn't only matter for Flash.

Comment 11

[(not reading bugmail) Nick Desaulniers [:\n]]

Attachment: additional dialog

Comment 12

[(not reading bugmail) Nick Desaulniers [:\n]]

It seems to me that when pref "plugin.allowed_types" is set, we should not be doing background checks for deprecated plugins that aren't on the whitelist.  See also [0].

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=755554#c2

Comment 13

[(not reading bugmail) Nick Desaulniers [:\n]]

John, any idea how the plugin update check code works (or where in the tree it is)?  As per my comment [0], I think we'll need to hook up that code to the whitelist you implemented in 755551.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=755551#c19

Comment 14

[(not reading bugmail) Nick Desaulniers [:\n]]

Speaking with Unfocused on IRC:
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/nsBlocklistService.js#1046
https://dxr.mozilla.org/mozilla-central/source/browser/base/content/test/general/head.js#191
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/nsBlocklistService.js#1302

Comment 15

[(not reading bugmail) Nick Desaulniers [:\n]]

This might be as simple a fix as setting the pref `extensions.blocklist.suppressUI`:

https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/nsBlocklistService.js#45
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/nsBlocklistService.js#1290-1303

Comment 16

[(not reading bugmail) Nick Desaulniers [:\n]]

Attachment: patch.txt

Comment 17

[(not reading bugmail) Nick Desaulniers [:\n]]

I seem to be unable to install apps in nightly currently.  Is this a known issue?

Comment 18

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 8568027 [details] [diff] [review]
patch.txt

This will work.  Just note that the pref was added in bug 1038145 for the purpose of suppressing the dialog during automated tests, so this is a new kind of use of it.  And thus it's in more danger of breaking, especially without automated tests of its own.  I won't require those here, given the sorry state of our test harness, but please file a followup to implement an automated test and another followup to enable the dialog in the runtime (for the edge case of a user who uses apps without using Firefox).

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/40dffb361899

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/40dffb361899