Closed Bug 1497555 Opened Last year Closed Last year

TP tour breaks because shield is not displayed on page load.


(Core :: Security: PSM, defect, P1)

64 Branch



Tracking Status
firefox-esr60 --- unaffected
firefox62 --- unaffected
firefox63 --- unaffected
firefox64 + verified


(Reporter: agibson, Assigned: keeler)



(Keywords: regression, Whiteboard: [psm-assigned])


(2 files)

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:64.0) Gecko/20100101 Firefox/64.0"

1. Visit `about:preferences#privacy and make sure Content Blocking is set to `on`.
2. Open

Expected results:

The Content Blocking shield icon should be displayed in the address bar and a UI doorhanger should be displayed anchored to it. Notice in the web console the page does say "The resource at “” was blocked because content blocking is enabled.", indicating that a tracker has been blocked.

Actual results:

The shield is not displayed, so the doorhanger does not show, breaking the tour.

Note: sometimes I do see the shield & things work, but this seems very intermittent.
Another observation: if the doorhanger shows on step 1, it often breaks once you try to proceed to step 3 because the sheild disappears again.
Attached image CP settings
Using nightly from 10-3-2018, with TP on and All third party cookies blocked, Shield appears in step 1 and 2.  Step 3 is broken, but I still see the shield in the url bar.  I'm not sure what is going on here.
Ok I think I've figured this out:

The tour uses `history.replaceState()` to update the URL params on each step of the tour [1]. It's this call that causes the shield to disappear, breaking the tour.

Pretty sure this also regressed with bug 1493563
Blocks: 1493563
Flags: needinfo?(ehsan)
Keywords: regression
Also, the original URL I provided in the description was slightly incorrect, it should have been: (pre-call to replaceState)
No longer blocks: 1493563
Keywords: regression
Blocks: 1493563
Keywords: regression
See Also: → 1495207
Fwiw, bug 1493563 seems to say resolved, fixed - but I still see the bug described here when testing in the latest Nightly.
(In reply to Johann Hofmann [:johannh] from comment #5)
> Pretty sure this also regressed with bug 1493563

This isn't right.

I ran mozregression for this, and I got to  This points to bug 1493427.  Locally backing out that bug fixes this also.

Dana, any chance you can have a look please?  Thanks!
Blocks: 1493427
No longer blocks: 1493563
Flags: needinfo?(ehsan) → needinfo?(dkeeler)
See Also: 1495207
One perhaps useful thing to know about this bug.  As I was going back in time using mozregression, the behavior of the bug changed when I got closer to the range.  The behavior right after bug 1493427 had landed was really strange and hard to explain, the popups would move unexpectedly on the screen and at some point the tab would get duplicated!  It might be worth running mozregression to get an idea of this behavior since you may not be able to see it on Nightly.
It looks like nsSecureBrowserUIImpl::OnLocationChange can ignore LOCATION_CHANGE_SAME_DOCUMENT events, unless anyone can think of a reason why that might be bad.
Assignee: nobody → dkeeler
Component: Tracking Protection → Security: PSM
Flags: needinfo?(dkeeler)
Priority: -- → P1
Product: Firefox → Core
Whiteboard: [psm-assigned]
If nsSecureBrowserUIImpl::OnLocationChange receives a
LOCATION_CHANGE_SAME_DOCUMENT notification, it doesn't need to (and in fact
shouldn't) update its security state or notify downstream listeners.
Pushed by
filter out same-document location changes in nsSecureBrowserUIImpl::OnLocationChange r=Ehsan
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
I verified this issue on Mac OS X 10.13 and 10.12 with FF Nightly 64.0a1 (2018-10-22) and I can confirm the fix.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.