The Security UI (TP shield, devtool console message) is updated when a resource is blocked in necko for TP reasons. That's currently done by the SetBlockedTrackingContent() function: https://dxr.mozilla.org/mozilla-central/rev/45273bbed8efaface6f5ec56d984cb9faf4fbb6a/netwerk/base/nsChannelClassifier.cpp#471 and in a normal e10s subresource load, that function is called twice (for the same channel URL) in two different nsIChannels (the parent and the child). However, in the case of Fetch/XHR loads, that function is only called once (in the parentChannel) so we can't update the UI. Without e10s, that function is called once in the child so everything works fine.

Steps to reproduce: 1. put both xhr.html and tracker.js in the local web server root 2. serve these files with a CORS header: <Directory /var/www/tp> Header set Access-Control-Allow-Origin: * </Directory> 3. redirect the hard-coded tracking domains to localhost through /etc/hosts file: 127.0.0.1 localhost itisatracker.org trackertest.org 4. add these domains as aliases in the web server config <VirtualHost localhost:80> ServerName localhost ServerAlias itisatracker.org ServerAlias trackertest.org </VirtualHost> 5. visit http://localhost/xhr.html under both e10s and non-e10s

Expected: In both e10s and non-e10s, we should see the TP shield in the URL bar and a devtool console warning. Actual: The shield and console message only work on non-e10s.

Bug 1232487 is another example of this problem, this time with assets loaded within Flash movies.

This test shows the symptoms described in comment 0. It's possible to actually write a test that we show the notification in the URL bar but I haven't written that part of the test yet. I'm going to use this to debug what's going on here. Now that I have this, it should be pretty simple to debug and fix this bug.

(In reply to Blake Kaplan (:mrbkap) (please use needinfo!) from comment #5) > This test shows the symptoms described in comment 0. Naming nit: the shield is no longer used for mixedcontent, it's only for tracking protection now. Also, if you want another quick way to test this, you can use the test case on https://bugzilla.mozilla.org/show_bug.cgi?id=1217236#c1

The comment in HttpChannelChild.cpp says it all. The CORs listener is stomping on our Cancel() value so we don't update the UI. This is a bit of a hack to recover the original reason the channel was canceled.

Comment on attachment 8700255 [details] [diff] [review] patch v1 Review of attachment 8700255 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/base/content/test/general/browser_trackingUI_6.js @@ +5,5 @@ > + let n = 0; > + let listener = { > + onSecurityChange: function() { > + n = n + 1; > + info ("Recieved onSecurityChange event " + n + " of " + numChanges); i before e, except after c :)

https://hg.mozilla.org/integration/mozilla-inbound/rev/74d2f955790a65ffd4a11075b08937536cfc5272 Bug 1229177 - Show the tracking protection shield for fetch and XHR requests. r=jduell

I tested with e10s both on and off, using test cases for fetch, XHR and Flash. Confirmed issue in Fx43.0.4. Verified fixed in Fx46 Nightly, 2016-01-18.

Blake should we uplift this to 45?

Comment on attachment 8700778 [details] [diff] [review] Patch for checkin Approval Request Comment [Feature/regressing bug #]: n/a [User impact if declined]: The user would not be notified about blocked content. [Describe test coverage new/current, TreeHerder]: I added a test for this case. [Risks and why]: Low risk, code touched only affects this specific case (NS_ERROR_TRACKING_URI). [String/UUID change made/needed]: n/a.

Comment on attachment 8700778 [details] [diff] [review] Patch for checkin has tests, fix a problem for the e10s experiment, taking it.