1657679 - ETP tracking content block list is empty and can't change the level

Status: VERIFIED FIXED

(Firefox :: Protections UI, defect)

Description

[Gary Chen [:xeonchen]]

Attachment: 1.png

I visited some websites and apparently some resources on CDNs are blocked as tracking content, so the content wasn't displayed correctly.

When I want to adjust the level of the block list, it's empty and nothing I can do.
This could be a bug and should be fixed.

Comment 1

[Gary Chen [:xeonchen]]

Attachment: 2.png

Comment 2

[Steven Englehardt [:englehardt]]

I suggest we entirely remove the list chooser UI and force Strict mode to use the Level 1 list for content blocking, rather than track down the specific issue. We know that using the Level 2 list for content blocking has caused a lot of site breakage, which led to us deprecating it in Bug 1568900. A recent change to the blocklist has made the breakage even more widespread: https://github.com/mozilla-services/shavar-list-creation/issues/153, to the point where this config will break any site that uses the cloudfront CDN.

Comment 3

[Steven Englehardt [:englehardt]]

I can reproduce this issue in beta but not release. Given that, I think we will have to patch this directly so we can uplift the fix. I filed Bug 1658044 for the eventual removal.

Comment 4

[Steven Englehardt [:englehardt]]

So it's clear: this UI is not available on new profiles. It is hidden behind the pref browser.contentblocking.customBlockList.preferences.ui.enabled, which was set to true for anyone who had changed their blocklist prior to our deprecation of the UI. You'll need to flip this pref manually to reproduce on a fresh profile.

Comment 5

[Steven Englehardt [:englehardt]]

Ran mozregression. It narrowed it down to:

2020-08-11T12:08:21.627000: INFO : Narrowed integration regression window from [2af48ca6, 97cef5b7] (3 builds) to [2af48ca6, d9b23a87] (2 builds) (~1 steps left)
2020-08-11T12:08:22.580000: DEBUG : Found commit message:
Bug 1642398: Add a lint rule to warn about multiple calls to document.l10n.formatValue. r=Standard8,preferences-reviewers,ntim

Differential Revision: https://phabricator.services.mozilla.com/D77900

2020-08-11T12:08:22.581000: DEBUG : Did not find a branch, checking all integration branches
2020-08-11T12:08:22.582000: INFO : The bisection is done.
2020-08-11T12:08:22.583000: INFO : Stopped

Comment 6

[Steven Englehardt [:englehardt]]

Attachment: Bug 1657679 - Revert formatting changes from Bug 1642398 to fix breakage; r=timhuang

Comment 7

[Steven Englehardt [:englehardt]]

This was caused by the changes in Bug 1642398, specifically attempting to access listName and description before they were declared. Since the formatting of name depends on listName and description, I don't see a way to avoid multiple calls to formatValue/formatValues. I've opted to disable the eslint rule for these two calls, in particular because this is a very low-touch UI surface that's disabled by default and that we'd eventually like to remove (see Bug 1658044).

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7b319b5aa79b
Revert formatting changes from Bug 1642398 to fix breakage; r=timhuang,preferences-reviewers,ntim

Comment 9

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/7b319b5aa79b

Comment 10

[Julien Cristau [:jcristau] (back April 22)]

Please request uplift when you get a chance.

Comment 11

[Steven Englehardt [:englehardt]]

Comment on attachment 9169525 [details]
Bug 1657679 - Revert formatting changes from Bug 1642398 to fix breakage; r=timhuang

Beta/Release Uplift Approval Request

• User impact if declined: Users who have this UI enabled (i.e., those who had changed their blocklist at the time we deprecated the UI in Bug 1568900) will continue to see the UI but will not be able to select a different list. This means they won't be able to recover from content blocking breakage without entirely disabling ETP Strict / content blocking in private browsing mode.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Steps are given in Comment 0 and Comment 4.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's a low-touch UI. The change is self-contained in the string construction for that UI, and is reverting a linting change that led to breakage.
• String changes made/needed: None

Comment 12

[Julien Cristau [:jcristau] (back April 22)]

Comment on attachment 9169525 [details]
Bug 1657679 - Revert formatting changes from Bug 1642398 to fix breakage; r=timhuang

regression fix, approved for 80 rc1

Comment 13

[Julien Cristau [:jcristau] (back April 22)]

https://hg.mozilla.org/releases/mozilla-beta/rev/10ac8767de96

Comment 14

[Ciprian Georgiu, Desktop QA]

I have managed to reproduce this bug using the info from comment 0 and 4, on an affected Nightly build i.e. 2020-08-06.

I can confirm that the block lists are showing up in about:preferences#privacy on the latest Nightly 81.0a1, under macOS 10.14, Win 10 x64 and Ubuntu 18.04 x64.

Also, I can confirm the followings:

• level 1 Tracker blocking List is correctly blocked on the https://senglehardt.com/test/trackingprotection/test_pages/tracking_protection.html testpage when "In all windows" option is selected, for the Tracking Content item (Level 1 block list)
• both level 1 and level 2 Tracker Blocking lists are correctly blocked on https://senglehardt.com/test/trackingprotection/test_pages/tracking_protection.html testpage when "In all windows" option is selected for the Tracking Content item (Level 2 block list)

Thanks Steven, for the additional details discussed on slack. I'll verify this on 80 rc1 as well, keeping the qe+ flag in place until then.

Comment 15

[Ciprian Georgiu, Desktop QA]

This issue is verified as fixed on 80.0-build2 (20200818235255) as well, under macOS 10.15, Win 10 x64 and Ubuntu 18.04 x64.