Closed Bug 1494744 Opened 6 years ago Closed 6 years ago

The Shield icon is not always displayed in the URL Bar, even if blockable resources are detected and blocked

Categories

(Firefox :: Protections UI, defect, P2)

63 Branch
defect

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox63 --- affected
firefox64 --- affected

People

(Reporter: JuliaC, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

[Note]:
- This is an intermittent issue (reproduced about 2 out of 10 attempts)
- For now I only managed to trigger this issue using https://www.reddit.com/ and slow-loading trackers resources

[Affected versions]:
- 63.0b9 build1 (20180924202103) 

[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. Open about:preferences#privacy and check the "Slow-Loading Trackers" entry from the Content Blocking section
3. Go to https://www.reddit.com/ and inspect the URL Bar and the Web Console logs

[Expected result]:
- Every time a slow tracking resource is detected and blocked (as reflected in Web Console), the Shield icon is also displayed in URL Bar

[Actual result]:
- There are cases when the Shield icon is not displayed in the URL Bar, even though the slow-loading trackers protection is enabled and related resources are detected and blocked
- For more details, see the following screenshot https://drive.google.com/file/d/1kB3ccrqGH6rlMF_v2t2vcovBRqOs4W9v/view?usp=sharing

[Regression range]:
- I will provide more details as soon as possible
See Also: → 1489525
It would be really helpful if you can do this while trying to reproduce:

  * Set these environment variables before launching Firefox:
    * MOZ_LOG=AntiTracking:5
    * MOZ_LOG_FILE=log.txt

    This will cause us to write a log file to disk from each process (parent process and child process) with information
    that will help us in debugging what happened.

  * Run Firefox, perform the test *on one page*.
  * If you didn't manage to reproduce, close Firefox, find the log files generated, delete them, and re-run Firefox and
    repeat the last step.
  * If you did manage to reproduce:
      * Paste the contents of the Web Console here in the bug.
      * close Firefox, find the log files generated, and attach them all to the bug.

These log files will be really helpful for us to determine what happened when the bug happens.  The steps above ensure that the log files capture only one page load each time, which will make it easier for us to go through the logs and make sense of them (the logs can be extremely long and verbose!).

Thanks!
Not sure if this is a fastblock issue or a UI issue.  Also unsure if there is a fastblock tag, so tagging this as privacy-panel-64 for triage.
Whiteboard: [privacy-panel-64][triage]
Priority: -- → P2
(In reply to Tanvi Vyas[:tanvi] from comment #2)
> Not sure if this is a fastblock issue or a UI issue.  Also unsure if there
> is a fastblock tag, so tagging this as privacy-panel-64 for triage.

My guess based on the code is that this would be a bug somewhere in the notification code that brings up the shield, the fact that it affects fastblock now is coincidental, third-party cookie blocking uses the same code with different flag values.
Iulia, another super helpful bit of information is whether this reproduces on latest Nightly.  We've had a few more fixes landed on trunk which haven't been backported there, it would be useful to know if we have accidentally fixed this already.  Do you mind testing on trunk as well?

If it doesn't reproduce on trunk, it would be nice to get a regression range on m-c to see what patch fixed it on Nightly.
The issue is quite intermittent, as I already mentioned and from dozens of attempts, I didn't manage to reproduce it without at least one tab reload. So I got the Web Console content and the logs for the reproduced scenario (it was triggered after one refresh). Also, I managed to reproduce it on latest Nightly. I will attach the contents for both Beta and Nightly.
Thanks a lot, Iulia!

Andrea, can you take a look please?
Flags: needinfo?(amarchesini)
I'm not able to reproduce this issue. I tried several times but nothing, the icon always appears.
It could be a timing issue, maybe hard to reproduce with a debug build.
Flags: needinfo?(amarchesini)
Priority: P2 → P3
Priority: P3 → P2
QA Contact: francois
Whiteboard: [privacy-panel-64][triage] → [privacy-panel]
Whiteboard: [privacy-panel] → [privacy65][triage]
Whiteboard: [privacy65][triage]
I'm closing this as INCOMPLETE.  We're removing the fastblock UI in bug 1502076, and while this bug may have another root cause, if that's the case we will hopefully see it elsewhere.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [privacy65][triage]
Whiteboard: [privacy65][triage]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: