1185117 - Investigate - TP shield shows up incorrectly when pressing back while loading a page with tracking elements

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Brian Grinstead [:bgrins]]

Attachment: shield-people.gif

There seems to be an issue with the way securityChange is reported when navigating back and forward (see STR below or the animated gif screencast).

1) Open http://people.mozilla.org/ (no tracking elements)
2) Navigate to cnn.com
3) Wait for a second and then press back while it is still loading.  If that doesn't work, press forward to go back to cnn and wait for 'a bit' before pressing back again (just long enough for the shield to show up).  It definitely depends on the timing, but I can get the shield to eventually show up on the people.mozilla.org site.

I have some logging in place and it looks like there is a securityChange event firing with STATE_BLOCKED_TRACKING_CONTENT (which is presumably due to a request that was being blocked during the page load of cnn when it was interrupted to go backwards).

Comment 1

[Brian Grinstead [:bgrins]]

Attachment: browser-console-logs.png

In addition to that, in the Browser Console I'm seeing messages that there are resources blocked on people.mozilla.org even though they originated from the other page (see screenshot)

The resource at "http://widgets.outbrain.com/outbrain.js" was blocked because tracking protection is enabled. people.mozilla.org
The resource at "http://secure-us.imrworldwide.com/cgi-bin/m?ci=us-204044h&cg=0&cc=1&si=http%3A//www.cnn.com/&rp=&ts=compact&rnd=1437168860603" was blocked because tracking protection is enabled. people.mozilla.org

François, do you have ideas about what is going on, or know who to direct this to?

Comment 2

[François Marier [:francois]]

(In reply to Brian Grinstead [:bgrins] from comment #1)
> Created attachment 8635541 [details]
> browser-console-logs.png
> 
> In addition to that, in the Browser Console I'm seeing messages that there
> are resources blocked on people.mozilla.org even though they originated from
> the other page (see screenshot)
> 
> The resource at "http://widgets.outbrain.com/outbrain.js" was blocked
> because tracking protection is enabled. people.mozilla.org
> The resource at
> "http://secure-us.imrworldwide.com/cgi-bin/m?ci=us-
> 204044h&cg=0&cc=1&si=http%3A//www.cnn.com/&rp=&ts=compact&rnd=1437168860603"
> was blocked because tracking protection is enabled. people.mozilla.org
> 
> François, do you have ideas about what is going on, or know who to direct
> this to?

That's quite strange. As if the browser is firing events for a page after leaving it for another.

CCing Javaun just so he knows about this problem.

Comment 3

[Matthew N. [:MattN]]

(In reply to François Marier [:francois] from comment #2)
> That's quite strange. As if the browser is firing events for a page after
> leaving it for another.

That could possibly be caused by a unload event handler making an XHR.

Comment 4

[Marco Mucci [:MarcoM]]

Investigation if issue is front-end or platform.  Follow up ticket for resolving the issue to be filed as necessary.

Comment 5

[Brian Grinstead [:bgrins]]

Found an easier STR:

1) Open a page with no trackers, like: `data:text/html,no tracking here`
2) Navigate to a page with the following content:

  <script>
  window.onunload = function() {
    var img = new Image();
    img.src = "http://trackertest.org";
    document.body.appendChild(img);
  }
  </script>

3) Go back.  This will cause the shield to show up on the first page

Comment 6

[Brian Grinstead [:bgrins]]

Using the simple STR from Comment 5, I've confirmed that that the webProgress object being passed in as the first argument to onSecurityChange has the wrong values set.  In this case, webProgress.DOMWindow.location and webProgress.currentURI are both pointing to the incorrect URL (the page from step 1, even though the onSecurityChange is firing due to blocked content on the page from step 2).

My best guess is that the docShell's mSecurityUI has already been updated to the new page when the channel classifier requests it [0].  This could also potentially lead to a bug where a third party tracking request is allowed to Site 1 during the onunload from Site 2 if the browser is navigating to Site 1.

[0]: https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsChannelClassifier.cpp#469

Comment 7

[Brian Grinstead [:bgrins]]

Attachment: tracking-unload.html

Comment 8

[Brian Grinstead [:bgrins]]

Closing this now since it was just for investigation and I've filed 1190450