Closed Bug 1498219 Opened 6 years ago Closed 6 years ago

"Content Blocking" disabled in a Private Window affects the content in a non-private window

Categories

(Firefox :: Protections UI, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1499549
Tracking Status
firefox63 --- fixed
firefox64 --- fixed

People

(Reporter: obotisan, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

[Affected versions]:
- Firefox 63.0b13
- Nightly 64.0a1

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

[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. Go to https://www.reddit.com/
3. Open a New Private Window and go to https://www.reddit.com/
4. In Private Window click on "Show site information" select "Disable Blocking Temporarily".
5. Go to the not-private window and refresh the page.

[Expected result]:
- "Content Blocking" is still enabled on the non-private page and the shield symbol is displayed on the screen.
- The messages like: 

"The resource at “https://www.googletagmanager.com/gtm.js?id=GTM-5XVNS82&l=googleTagManager” was blocked because content blocking is enabled." 

are still displayed in the console for the non-private window. 


[Actual result]:
- "Content Blocking" is still enabled on the non-private page, but the shield symbol is not displayed on the screen and even after refresh it doesn't appear anymore.
- The messages like: 

"The resource at “https://www.googletagmanager.com/gtm.js?id=GTM-5XVNS82&l=googleTagManager” was blocked because content blocking is enabled." 

are not displayed anymore in the console for the non-private window. 


[Regression range]:
- If there is a regression I will find it and will post it in a comment.

[Additional Notes]:
- If you enable the Content Blocking from the private window and refresh the non-private window, then the shield is displayed on the non-private window.
It sounds like the exception is handled properly but that the UI gets confused.
Regression:
- last good: 2018-09-04
- first bad: 2018-09-05
Mozregression concluded that Bug 1487396 (Part 6: Turn the FastBlock pref off during the test runs where we were previously relying on it being off by default) might cause this issue.
Keywords: regression
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.