Closed Bug 1496375 Opened 3 years ago Closed 3 years ago

The toggle off behavior of Content Blocking is inconsistent between the Burger menu and about:Preferences


(Firefox :: Site Identity, defect)

Not set



Firefox 64
Tracking Status
firefox-esr60 --- unaffected
firefox62 --- unaffected
firefox63 --- disabled
firefox64 --- fixed


(Reporter: vlucaci, Assigned: ehsan.akhgari)


(Keywords: regression, Whiteboard: [privacy-panel])


(2 files)

[Affected versions]:

- 63.0b11
- 64.0a1 (2018-10-03)
- 63.0b1 DevEd 

[Affected platforms]:
- Windows 10x64
- macOS 10.13.6
- Ubuntu 16.04

[Steps to reproduce]:

Precondition: Content Blocking must be enabled (set browser.contentblocking.ui.enabled to true and restart the browser) if isn't already.

1. Launch Firefox

2. Visit any website (ex:

3. Open the URL bar site information doorhanger.

4. Click to Add Blocking for Slow-Loading Trackers.

5. Check the Slow-Loading Trackers option from about:preferences#privacy from the Content Blocking section

6.Return to the visited website tab and check the URL bar site information doorhanger.(The Slow-Loading Trakers now appear as Blocked)

7.Go to the Burger Menu and disable the Content Blocking feature from the toggle button.

8.Return to the URL doorhanger, notice the red Disabled tag and the fact that Slow-Loading Trackers appear as blocked.

9.Return to the Burger menu and re-activate the Content Blocking feature from the toggle button.

10.Visit about:preferences#privacy ,Content Blocking section, and disable the feature from there.

11.Return to the visited website tab, check the URL doorhanger.
[Expected result]:

- The doorhanger information for Content blocking should be displayed in the same manner like in Step 8.

[Actual result]:

- The doorhanger information for Content blocking is inconsistent when disabling the feature from "about:preferences#privacy" vs the "Burger Menu" .
This time , the Disabled red tag is displayed, however none of the previously saved blocking options will be saved.("Add blocking..." option will be displayed instead of "Blocked"

[Regression range]:

-This seems to be a recent regression:

[Additional notes]:

- Keeping in mind that both toggle buttons of the Content Blocking ,that are found in "about:preferences#privacy" & "Burger Menu" ,have the same(On/Off)function it makes sense that both must render the same information in the URL doorhanger for both cases.

My suggestion would be that the most useful way to the user to display this information when disabling the feature would be with the Red Disabled tag alongside with the previously blocked options marked with the grey Blocked text.
So in one case it says "Add Blocking..." and in the other "Blocked"? Huh, interesting bug but it seems like an edge case.
Component: Preferences → Site Identity and Permission Panels
Whiteboard: [privacy-panel-64][triage]
Hello Johann,

Please take your time and re-visit the issue carefully.

The fact that the user has 2 different behaviors of the Content Blocking doorhanger information with the action of basically the same Off button (just in two different locations) is a huge inconsistency issue.

And it is not at all an Edge case; All the user has to do is simply set up the types of blocks he is interested in, and disable the Content blocker feature from about:preferences#privacy, then re-visit the URL site information doorhanger.

Reading the STR carefully ,it can be noticed that it is a description comparison between disabling the feature from the Hamburger Menu vs from about about:preferences#privacy.

The fact still remains that the user simply has to disable (toggle off)  the feature from about:preferences#privacy and all the block types will be lost (and will only return when turning the feature back ON, from the same section,not from the burger menu) ;not even a page refresh will fix this problem.
I'm not sure why this is happening.  In both cases (whether you disable from hamburger menu or from the Preferences menu, the browser.fastblock.enabled is still true, so we are preserving the global state.  I'm not sure why it is propogating differently when you turn off Content Blocking from the hamburger menu.  The Control Center doesn't seem to update in the case when you make the change from the hamburger menu.

But note, when I refresh or even just switch tabs for a second and come back, the Control Center is up to date with the "Add Blocking..." text.  Given this, it may just be a short delay in control center updating.

But Vlad reports that the issue persists after refresh.  I cannot reproduce that.

Either way, this seems like a P3.  Also, note that in Firefox 63 we will not be exposing the global toggle.  This was recently decided.  The global toggle probably won't be available until 65.
Whiteboard: [privacy-panel-64][triage] → [privacy-panel]
The hamburger toggle button is turned off on beta, adjusting 63 status accordingly.
Assignee: nobody → ehsan
Pushed by
Update the blocker category states when the content blocking pref value changes r=johannh
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Hello all,

There are several issues here that need to be addressed before I can leave a resolution for this ticket.

This ticket has been marked as fixed in 64. But as you can see in Comment 3 and Comment 4 , it states that the toggle buttons will not be present at all for that beta. I can confirm this as the toggle buttons are not present at all in all of the 64 betas released so far.

And as you can see in Comment 3, Tanvi stated that "The global toggle probably won't be available until 65." . I can also confirm that the buttons were present in Nightly, but only from the first 65.0a1 (2018-10-22) build until 65.0a1 (2018-10-27). All of the other nightly releases after that (including the latest 65.0a1 (2018-10-30)) are without the toggle buttons.

If someone has the time, could you please help me clarify these issues? 
Thank you in advance.
Flags: needinfo?(ehsan)
The toggle buttons were removed for good and I don't think needs any further verification :)
Flags: qe-verify-
Flags: qe-verify+
Flags: needinfo?(ehsan)
You need to log in before you can comment on or make changes to this bug.