1152119 - Tracking protection shield doesn't show up on pages that have a script blocked due to a CORS issue [e10s]

Status: RESOLVED DUPLICATE of bug 1152574

(Core :: DOM: Security, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

STR:
Enable privacy.trackingprotection.enabled
Load http://genius.it/5088375/ejohn.org/files/jquery-original.html
Look in Web Console

ER:
No errors

AR:
A script is blocked on the page due to an issue with CORS [1], and there is no Tracking Protection shield in the location bar.

[1] Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://genius.com/bookmarklets/injection.js?s=proxy. (Reason: CORS request failed).

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

This was seen with Nightly v40.0a1 2015-04-07 on Windows 8.1.

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

Francois, can you take a look? If it's a CORS problem, I will take over.

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

What we know so far: The error that gets logged to the console only gets logged here:
http://mxr.mozilla.org/mozilla-central/source/dom/security/nsCORSListenerProxy.cpp#538

Comment 4

[François Marier [:francois]]

Trying this on Nightly 40.0a1 2015-04-07 on Linux, I get the TP shield and I also see this in the console:

> The resource at "http://genius.com/bookmarklets/injection.js?s=proxy" was blocked because tracking protection is enabled. jquery-original.html
> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://genius.com/bookmarklets/injection.js?s=proxy. (Reason: CORS request failed).

Are you sure you have TP turned ON?

https://people.mozilla.org/~fmarier/tracking-test/

As for the fact that genius.com itself is blocked by TP, I think that is in fact a mistake. It looks like that domain used to belong to an ad company but that it has since changed ownership. I will check with Disconnect.

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Yes, I confirmed that I had tracking protection enabled. The steps in comment #0 reproduced the issue for me, and I also confirmed that disabling the `privacy.trackingprotection.enabled` pref fixed the issue.

Comment 6

[François Marier [:francois]]

I found a way to reproduce it: you must have e10s turned ON.

Comment 7

[François Marier [:francois]]

Attachment: Minimal test case

Here's a minimal test case for this bug.

Without e10s, the shield is visible and this is what's in the devtools console:

- The resource at "https://extremetracking.com/" was blocked because tracking protection is enabled.
- Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://extremetracking.com/. (Reason: CORS request failed).

With e10s, only the second message shows up ("Cross-Origin Request Blocked..."). The shield doesn't appear.

If I remove "crossorigin" from the script element, then the devtools messages are the same with or without e10s:

- The resource at "https://extremetracking.com/" was blocked because tracking protection is enabled.

and the shield appears.

Comment 8

[François Marier [:francois]]

Attachment: Minimal test case

Comment 9

[François Marier [:francois]]

Christoph, I think there might be a CORS problem here.

When the request is cancelled due to being blocked by TP, this check fails:

  https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCORSListenerProxy.cpp#541

and that causes the log about the CORS failure to be sent to the devtools console.

The problem is that in this case "status == NS_ERROR_TRACKING_URI" and that has nothing to do with CORS (the server is indeed correctly configured for CORS). I don't think we should be printing a CORS error to the devtools console when the request is blocked by TP. There are probably other NS_ERROR_* that shouldn't lead to the CORS error message either. What do you think?

Comment 10

[Kohei Yoshino [:kohei]]

The same issue has been reported for GitHub and I can reproduce it when e10s is enabled on OS X.

https://twitter.com/magsout/status/600655996227362816

Comment 11

[Christoph Kerschbaumer [:ckerschb]]

(In reply to François Marier [:francois] from comment #9)
> Christoph, I think there might be a CORS problem here.
> 
> When the request is cancelled due to being blocked by TP, this check fails:
> 
>  
> https://dxr.mozilla.org/mozilla-central/source/dom/security/
> nsCORSListenerProxy.cpp#541
> 
> and that causes the log about the CORS failure to be sent to the devtools
> console.
> 
> The problem is that in this case "status == NS_ERROR_TRACKING_URI" and that
> has nothing to do with CORS (the server is indeed correctly configured for
> CORS). I don't think we should be printing a CORS error to the devtools
> console when the request is blocked by TP. There are probably other
> NS_ERROR_* that shouldn't lead to the CORS error message either. What do you
> think?

That sounds like a very reasonable explanation to me. We should account for different errors, at least for tracking protection error for now to not incorrectly display that error in the console.

Comment 12

[Christoph Kerschbaumer [:ckerschb]]

In fact this bug is a duplicate of Bug 1152574. Fixing the issue over in Bug 1152574.