Closed Bug 1152119 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: DOM: Security, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1152574
Tracking Status
e10s m8+ ---

People

(Reporter: jaws, Assigned: mrbkap)

References

Details

(Keywords: site-compat)

Attachments

(1 file, 1 obsolete file)

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).
This was seen with Nightly v40.0a1 2015-04-07 on Windows 8.1.
Francois, can you take a look? If it's a CORS problem, I will take over.
Flags: needinfo?(francois)
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
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.
Flags: needinfo?(francois) → needinfo?(jaws)
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.
Flags: needinfo?(jaws)
I found a way to reproduce it: you must have e10s turned ON.
Blocks: 1029886
Summary: Tracking protection shield doesn't show up on pages that have a script blocked due to a CORS issue → Tracking protection shield doesn't show up on pages that have a script blocked due to a CORS issue [e10s]
Assignee: nobody → mrbkap
tracking-e10s: --- → m8+
Attached file Minimal test case (obsolete) —
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.
Attached file Minimal test case
Attachment #8591482 - Attachment is obsolete: true
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?
Flags: needinfo?(mozilla)
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
Keywords: site-compat
OS: Windows 8.1 → All
Hardware: x86_64 → All
(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.
Flags: needinfo?(mozilla)
In fact this bug is a duplicate of Bug 1152574. Fixing the issue over in Bug 1152574.
Status: NEW → RESOLVED
Closed: 6 years ago
No longer depends on: 1152574
Resolution: --- → DUPLICATE
Duplicate of bug: 1152574
You need to log in before you can comment on or make changes to this bug.