The default bug view has changed. See this FAQ.

FF16 CTP blocklist should never be triggered

RESOLVED FIXED in Firefox 16

Status

()

Toolkit
Add-ons Manager
--
blocker
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: akeybl, Assigned: keeler)

Tracking

({verifyme})

16 Branch
mozilla16
verifyme
Points:
---

Firefox Tracking Flags

(firefox16+ fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
FF16 CTP blocklisting functionality should never be triggered by a remote blocklist given the minimal QA it has received thus far.
Adding Paul Silaghi as the QA Contact since he is the QA Owner for CTP. Paul, once the engineering work is done here, please test whatever Alex needs.
QA Contact: paul.silaghi
Can't we use the targetApplication tag in the blocklist to make any ctp blocks not apply to 16? I'd rather do something like that that's a bit more flexible in case we do decide to use blocklisting ctp in 16 (very unlikely, I know, but it would be nice to have the option).
(Reporter)

Comment 3

5 years ago
(In reply to David Keeler from comment #2)
> Can't we use the targetApplication tag in the blocklist to make any ctp
> blocks not apply to 16? I'd rather do something like that that's a bit more
> flexible in case we do decide to use blocklisting ctp in 16 (very unlikely,
> I know, but it would be nice to have the option).

CTP in FF16 is completely untested and should never be used. The only reason to leave the functionality in is if disabling it completely isn't low risk.
Seems like we can leave this in, test in parallel then decide whether this is usable?
(Reporter)

Comment 6

5 years ago
(In reply to Lucas Adamski from comment #5)
> Seems like we can leave this in, test in parallel then decide whether this
> is usable?

This isn't a good use of QA or support resources.

We would need to specify all CTP blocklists as FF17 and up if we do not disable the functionality completely. I'm worried about accidentally enabling the untested functionality.
(In reply to Alex Keybl [:akeybl] from comment #6)
> We would need to specify all CTP blocklists as FF17 and up if we do not
> disable the functionality completely.

Don't we need to do that anyway? If any version of firefox prior to 16 gets a blocklist with a click-to-play entry that applies to it, it'll show the out-of-date plugin infobar, which I thought was also something we didn't want to do (this may be my misunderstanding - I'm just extrapolating from how often we've decided to not use the old blocklist functionality).

I don't understand why we're reluctant to use this nifty feature of the blocklist where we can say "this block only applies to these version of firefox".
(Reporter)

Comment 8

5 years ago
(In reply to David Keeler from comment #7)
> (In reply to Alex Keybl [:akeybl] from comment #6)
> > We would need to specify all CTP blocklists as FF17 and up if we do not
> > disable the functionality completely.
> 
> Don't we need to do that anyway? If any version of firefox prior to 16 gets
> a blocklist with a click-to-play entry that applies to it, it'll show the
> out-of-date plugin infobar, which I thought was also something we didn't
> want to do (this may be my misunderstanding - I'm just extrapolating from
> how often we've decided to not use the old blocklist functionality).

The infobar block is what we used for the recent Java block - it's the only desirable experience we currently have. So this bug specifically would force us to specifically exclude FF16 from future CTP blocklists.
Because of the way the blocklist form currently works we can only limit a plugin block to either a plugin version range *or* an application version range. This means that if we needed to implement a CTP block on a plugin version range, we would be forced to include Firefox 16 in that block.
(Reporter)

Comment 10

5 years ago
(In reply to Jorge Villalobos [:jorgev] from comment #9)
> Because of the way the blocklist form currently works we can only limit a
> plugin block to either a plugin version range *or* an application version
> range. This means that if we needed to implement a CTP block on a plugin
> version range, we would be forced to include Firefox 16 in that block.

Given this, and the other risks outlined, I'm designating this bug as a blocker for release.
Severity: normal → blocker
Created attachment 665966 [details] [diff] [review]
patch

Blair - we need to prevent click-to-play blocklisting on FF16, and I'm pretty sure this is the simplest, safest way to do it. Since you reviewed the patch that added this feature, I figured you'd be a good pick to review the patch that takes it out :)
Attachment #665966 - Flags: review?(bmcbride)
(Reporter)

Comment 12

5 years ago
(In reply to David Keeler from comment #11)
> Created attachment 665966 [details] [diff] [review]
> patch
> 
> Blair - we need to prevent click-to-play blocklisting on FF16, and I'm
> pretty sure this is the simplest, safest way to do it. Since you reviewed
> the patch that added this feature, I figured you'd be a good pick to review
> the patch that takes it out :)

Some context for Blair - we need to land this on mozilla-beta Monday, so please prioritize this review. Thanks!
Comment on attachment 665966 [details] [diff] [review]
patch

Review of attachment 665966 [details] [diff] [review]:
-----------------------------------------------------------------

Yep.
Attachment #665966 - Flags: review?(bmcbride)
Attachment #665966 - Flags: review+
Attachment #665966 - Flags: approval-mozilla-beta?
(Reporter)

Comment 14

5 years ago
Comment on attachment 665966 [details] [diff] [review]
patch

[Triage Comment]
Approving this disable to land asap so that we can be confident in future CTP/infobar blocklist rollouts.
Attachment #665966 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
https://hg.mozilla.org/releases/mozilla-beta/rev/7520d2746f3f
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-firefox16: --- → fixed
Component: General → Add-ons Manager
Product: Firefox → Toolkit
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
Version: unspecified → 16 Branch
Paul, please make sure you target this for extensive testing with the next Firefox 16 Beta.
Keywords: verifyme
Roger that. Waiting for the beta builds
https://bugzilla.mozilla.org/show_bug.cgi?id=797378#c23 indicates that this is not working correctly.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #18)
> https://bugzilla.mozilla.org/show_bug.cgi?id=797378#c23 indicates that this
> is not working correctly.

Please see https://bugzilla.mozilla.org/show_bug.cgi?id=797378#c27
You need to log in before you can comment on or make changes to this bug.