Closed Bug 1497555 Opened Last year Closed Last year
TP tour breaks because shield is not displayed on page load
"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 https://www.mozilla.org/en-US/firefox/64.0/tracking-protection/start/?newtab=true&step=1 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 “https://trackertest.org/” 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.
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 . It's this call that causes the shield to disappear, breaking the tour.  https://github.com/mozilla/bedrock/blob/master/media/js/firefox/tracking-protection-tour.js#L311
Pretty sure this also regressed with bug 1493563
Also, the original URL I provided in the description was slightly incorrect, it should have been: https://www.mozilla.org/en-US/firefox/64.0/tracking-protection/start/?newtab=true (pre-call to replaceState)
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 https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0d4e73bc2cd705d7a021c75a0e8aeb174ab4db59&tochange=9e0a27bf253e61088a726d4235cae2b73250dd69. This points to bug 1493427. Locally backing out that bug fixes this also. Dana, any chance you can have a look please? Thanks!
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
Priority: -- → P1
Product: Firefox → Core
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 firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/a87fc8375ec2 filter out same-document location changes in nsSecureBrowserUIImpl::OnLocationChange r=Ehsan
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.
You need to log in before you can comment on or make changes to this bug.