1590696 - [Fission] Blocked loads are not recorded in the content blocking log and no content blocking event is fired

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect, P1)

Description

[(inactive) Nihanth Subramanya [:nhnt11]]

STR:
Run mach test --enable-fission browser/base/content/test/trackingUI/browser_trackingUI_animation.js - the test will fail, and get stuck waiting for content blocking events. At this point you can open the browser console and look at the content blocking log of the selected browser. It will be empty, but you should be able to see the message in the console that the load was blocked.

As far as I can tell the load is definitely blocked, but the Content Blocking event doesn't propagate and isn't recorded in the log. Content blocking events seem to be propagated correctly for cookie blocking.

I'll try to investigate this in the near future but I'm not optimistic about my ability to fix this. This blocks a bunch of trackingUI tests, and I'll be documenting that in another bug shortly.

Comment 1

[Dimi Lee [:dimi]]

just a quick update that this probably is because of ThirdPartyUtil::GetTopWindowForChannel can not get the 'real' top level window when fission is enabled. We use that window(about:blank in this case) to call NotifyContentBlockingEvent and it ends up failing to pass the SameLoadingURI check here.

Comment 2

[Johann Hofmann [:johannh]]

Wanted to mention that this is very similar to the issue found in bug 1451307, so if you could fix that bug along the way I won't mind. I already had patches for that one (though the fix for the fission case might be slightly different), but failed to land because of weird Fennec test failures.

Comment 3

[Dimi Lee [:dimi]]

There is also Bug 1586189 which tries to fix ThirdPartyUtil::GetTopWindowForChannel, I'll test if the proposed solution in that patch can help this one

Comment 4

[Dimi Lee [:dimi]]

(In reply to Dimi Lee [:dimi][:dlee] from comment #3)

There is also Bug 1586189 which tries to fix ThirdPartyUtil::GetTopWindowForChannel, I'll test if the proposed solution in that patch can help this one

sorry, I made a mistake, that one is differnt, please ignore Comment 3 :(

Comment 5

[(inactive) Nihanth Subramanya [:nhnt11]]

Just for the record: pretty much all the trackingUI tests that are currently blocking fission M4 are affected by this bug. Here they are:

browser_trackingUI_animation.js
browser_trackingUI_animation_2.js
browser_trackingUI_background_tabs.js
browser_trackingUI_cookies_subview.js
browser_trackingUI_cryptominers.js
browser_trackingUI_fingerprinters.js
browser_trackingUI_open_preferences.js
browser_trackingUI_pbmode_exceptions.js
browser_trackingUI_report_breakage.js
browser_trackingUI_socialtracking.js
browser_trackingUI_state.js
browser_trackingUI_state_reset.js
browser_trackingUI_telemetry.js
browser_trackingUI_trackers_subview.js

Comment 6

[Jean-Yves Avenard [:jya]]

(In reply to Nihanth Subramanya [:nhnt11] from comment #0)

As far as I can tell the load is definitely blocked, but the Content Blocking event doesn't propagate and isn't recorded in the log. Content blocking events seem to be propagated correctly for cookie blocking.

Note that following bug 1588241 cookie blocking won't be propagated either.

How events were propagated was wrong, it was being sent to the original content process that initiated the load, not the content process where the load will actually be happening (wrong origin).

Not sending those events to the original content process is the right thing to do.

Comment 7

[Matt Woodrow (:mattwoodrow)]

pernosco link for this is here: https://pernos.co/debug/iI0qHEIUi5JsLzXp-6xPcw/index.html#f{m[BA2O,B8RB_,t[AXk,CQQ_,f{e[BA2O,B8Q3_,s{af88GYtAA,bASE,oDlS7ig,uDjtJpA___

We get as far as BrowserChild::OnContentBlockingEvent, but don't forward it to the parent process.

It looks like RemoteWebProgress isn't currently support for OOP iframes, should be fixed by bug 1580752.

Comment 8

[Chris Peterson [:cpeterson]]

Tentatively moving all bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to the "?" triage milestone.

This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

Comment 9

[Chris Peterson [:cpeterson]]

Tracking ETP work for Fission Nightly milestone (M6).

Comment 10

[(no longer active)]

All of these tests now pass due to the work that was done in bug 1599046.

Comment 11

[(no longer active)]

Attachment: Bug 1590696 - Mark most of the tests in browser/base/content/test/trackingUI as Fission compatible now that the content blocking log has been moved to the parent process;

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2d97b7a7e064
Mark most of the tests in browser/base/content/test/trackingUI as Fission compatible now that the content blocking log has been moved to the parent process; r=nhnt11

Comment 13

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/2d97b7a7e064