Closed Bug 1496671 Opened 3 years ago Closed 3 years ago
Final pref changes for Content Blocking in Firefox 63
[Tracking Requested - why for this release]: This bug is tracking the final set of pref flips for shipping the Content Blocking feature (including FastBlock, Tracking Protection and Cookie Restrictions) in Firefox 63. We will decide on the final list of features to be released and their status (enabled or disabled by default) based on the results of the currently running Shield studies. This will also impact whether the Content Blocking or Tracking Protection UI will be shown. Needinfo for Tanvi and pdol to confirm the desired changes
Please let me know whenever we have a decision on how to move forward based on the results of the study. I assume I'll be in those meetings as well, just flagging you here to make sure we don't forget.
The behavior of report breakage button for release 63 is being taken care of in this bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1496557. For the rest of the Control Center and Preferences, what we want in 63 release is this: * Content Blocking UI in preferences and control center exposed * No global toggle for content blocking (the blue switch) in preferences or in the hamburger menu. * No UI for Fastblock (Slow-Loading Trackers) in Preferenes or in Control Center * Include UI for Tracking Protection, no named "All Detected Trackers" in 63 and "Trackers" in 64. Both in Control Center and Preferences * Include UI for Third-Party Cookies in both control center and preferences. * Include the "recommended" string next to the option that blocks third party cookies from trackers. These are the prefs that need to be changed for release to make the above happen: browser.contentblocking.fastblock.ui.enabled = false browser.contentblocking.fastblock.control-center.ui.enabled = false browser.contentblocking.global-toggle.enabled = false browser.contentblocking.ui.enabled = true Johann, please make a patch that changes these prefs for release and test that it does what is described above for release. Also, we should consider what we want beta to look like, since I'm sure your changes will impact beta as well. * For the fastblock prefs, those should probably be true within an ifdef early beta, and false otherwise. * The contentblocking.ui.enabled pref can be set to true for all channels, so you can remove the ifdef. * The global toggle can be on in Nightly where Fastblock is enabled by default (and soon cookie restrictions will be too). For beta, we can disable the global toggle. We will leave it disabled until we have a default-on feature in beta. Pdol, please review and confirm the above sounds good to you on Tuesday. Thanks!
This all looks good to me. Yes, please feel free to proceed with landing these changes.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/09728d62f4d0 Final pref changes for Content Blocking in Firefox 63. r=Gijs,baku
Comment on attachment 9015469 [details] Bug 1496671 - Final pref changes for Content Blocking in Firefox 63. r=Gijs,baku [Beta/Release Uplift Approval Request] Feature/Bug causing the regression: None User impact if declined: Users stay in the old Tracking Protection UI, but we want to ship the cool new Content Blocking UI. Is this code covered by automated tests?: Yes Has the fix been verified in Nightly?: No Needs manual test from QE?: Yes If yes, steps to reproduce: After uplift, Beta should have the Content Blocking UI known from Nightly, with the exception that FastBlock should not be mentioned because we're not shipping it. List of other uplifts needed: None Risk to taking this patch: Medium Why is the change risky/not risky? (and alternatives if risky): The new UI has been in central for a long time and has baked sufficiently on Nightly and undergone QA testing there, however, it has been pref-ed off in Beta so far for most of the population and thus hasn't gotten bake time there. String changes made/needed: None
Attachment #9015469 - Flags: approval-mozilla-beta?
(In reply to Johann Hofmann [:johannh] from comment #7) > Needs manual test from QE?: Yes > > If yes, steps to reproduce: After uplift, Beta should have the Content > Blocking UI known from Nightly, with the exception that FastBlock should not > be mentioned because we're not shipping it. Also, the blue global toggle for Content Blocking in the main menu and about:preferences should not exist in beta.
Comment on attachment 9015469 [details] Bug 1496671 - Final pref changes for Content Blocking in Firefox 63. r=Gijs,baku Approved for uplift to our last 63 beta. Thanks.
Attachment #9015469 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Cornel, this uplift will require a close look at from QA, thanks!
Hello all, This issue is verified fixed for both 63.0b14 and 64.0a1. I have verified all the uplift changes and everything is as described by Tanvy in Comment 2.
Was the intent to just remove the toggle from the main menu? or also the label Content Blocking? I am in Nightly and flipped the prefs per Tanvi's instructions in Comment 2 but still have a label in the main menu, but not a toggle.
(In reply to mheubusch from comment #13) > Was the intent to just remove the toggle from the main menu? or also the > label Content Blocking? I am in Nightly and flipped the prefs per Tanvi's > instructions in Comment 2 but still have a label in the main menu, but not a > toggle. I believe we should still have the label in the hamburger menu, but removed the toggle. Tanvi please confirm.
Do you have already seen promising numbers on Nightly and Beta or would you like to wait and look if the awesome adoption rate (https://data.firefox.com/dashboard/usage-behavior) really regresses on Release and only then restore "Tracking Protection" (by reverting bug 1476224)? Thanks
The intent is to remove the blue switch, but not the title.
You need to log in before you can comment on or make changes to this bug.