Affected versions

• 66.0b13
• 67.0a1 (2019-03-07)

Affected platforms

• Windows 10x64
• Windows 7x64
• macOs 10.13
• Ubuntu 18.04x64

Steps to reproduce

1. Go to https://senglehardt.com/test/trackingprotection/test_pages/index.html. Note the lack of shield.
2. Right click "Fingerprinting and Cryptomining and Trackers" and open in a new tab.
3. New tab is opened.

Expected result

• The shield is displayed.

Actual result

• The shield is displayed just after refreshing the page.

Regression range

• First bad: 2a82b9a67559d93cd57ff9738b782fb43717afd1
• Last good: 492e4409f468f4841def795627356148d0bb7347
• Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=492e4409f468f4841def795627356148d0bb7347&tochange=2a82b9a67559d93cd57ff9738b782fb43717afd1
• Potentially regressed by: 1479335

(In reply to Maria Berlinger [:maria_berlinger], Release Desktop QA from comment #0)

Regression range

• First bad: 2a82b9a67559d93cd57ff9738b782fb43717afd1
• Last good: 492e4409f468f4841def795627356148d0bb7347
• Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=492e4409f468f4841def795627356148d0bb7347&tochange=2a82b9a67559d93cd57ff9738b782fb43717afd1
• Potentially regressed by: 1479335

This doesn't look right, as that bug was backed out in the same window.

That said, I don't see anything else in that window that looks related, either.

Yeah, pretty sure bug 1527151 broke this, I'll investigate...

When switching tabs (which is what ultimately happens here, you open a new tab in the background and then switch to it), we use the securityUI.contentBlockingEvent property to update the shield state. That property is set in https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/browser/base/content/browser.js#5025. Unfortunately, that event is only received by the current browser https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/browser/base/content/tabbrowser.js#754. Thus, the background tab is not storing its content blocking event.

That means we might have no choice but to update the contentBlockingEvent earlier. Unfortunately we just added telemetry code that relies on the contentBlockingEvent property being set after the onContentBlockingEvent handler in browser-contentblocking.js runs. Maybe we can have another special code path for background tabs.

Not considering loads in background tabs was clearly a big oversight.

GAH.

When switching tabs we use the securityUI.contentBlockingEvent property to update the shield state.

That property is set in https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/browser/base/content/browser.js#5025.

Unfortunately, that event is only received by the current browser because is is registered with gBrowser.addProgressListener instead of gBrowser.addTabsProgressListener. Thus, the background tab is not storing its content blocking event.

To fix this, we also listen for content blocking events with addTabsProgressListener, but exclude the
currently selected tab there.

https://hg.mozilla.org/mozilla-central/rev/f6a8502a80bf

I have reproduced this bug with Nightly 67.0a1 (2019-03-07) on Windows 7, 64 Bit. The fix of this bug is verified with latest Beta 67.0b5!

Build ID 20190325125126
User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

This issue is verified fixed using Firefox 67.0b5 and Firefox 68.0a1(2019-03-28) on the following oses: Windows 10x64, Windows 7x64, macOs 10.13, Ubuntu 18.04x64.