Closed Bug 1533362 Opened 8 months ago Closed 8 months ago

The shield isn't displayed when opening link in new tab

Categories

(Firefox :: Site Identity, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 67
Tracking Status
firefox-esr60 --- unaffected
firefox65 --- unaffected
firefox66 --- wontfix
firefox67 --- verified
firefox68 --- verified

People

(Reporter: maria_berlinger, Assigned: johannh)

Details

(Keywords: regression, Whiteboard: [anti-tracking])

Attachments

(1 file)

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

Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(jhofmann)

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

Regression range

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...

No longer blocks: 1479335
Flags: needinfo?(jhofmann)
Priority: -- → P2
Flags: needinfo?(jhofmann)

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.

Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Flags: needinfo?(jhofmann)
Priority: P2 → P1
Whiteboard: [anti-tracking]

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.

Pushed by jhofmann@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f6a8502a80bf
Record contentBlockingEvent for background tabs. r=Ehsan
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
Flags: in-testsuite+

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

QA Whiteboard: [bugday-20190320]

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.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.