Closed Bug 1590696 Opened 1 year ago Closed 10 months ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla75
Fission Milestone M6
Tracking Status
firefox75 --- fixed

People

(Reporter: nhnt11, Assigned: ehsan)

References

Details

Crash Data

Attachments

(1 file)

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.

Summary: Blocked loads are not recorded in the content blocking log and no content blocking event is fired → [Fission] Blocked loads are not recorded in the content blocking log and no content blocking event is fired

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.

Assignee: nobody → dlee
Status: NEW → ASSIGNED

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.

Priority: -- → P1
See Also: → 1451307

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
Assignee: dlee → nobody
Status: ASSIGNED → NEW

(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.

See Also: → 1588241
Depends on: 1580752

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.

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

Fission Milestone: --- → ?

Tracking ETP work for Fission Nightly milestone (M6).

Fission Milestone: ? → M6

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

Depends on: 1599046
No longer depends on: 1580752
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #9125183 - Attachment description: Bug 1590696 - Mark all 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; → 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;
Pushed by eakhgari@mozilla.com:
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
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla75
Blocks: 1572050
Duplicate of this bug: 1574939
Crash Signature: [@ mozilla::ipc::FatalError(char const*, bool)]
You need to log in before you can comment on or make changes to this bug.