BounceTrackingState::OnStartNavigation is not called for parent-initiated top level loads
Categories
(Core :: Privacy: Anti-Tracking, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox155 | --- | fixed |
People
(Reporter: emz, Assigned: emz)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Top level navigations that are initiated in the parent process go through DocumentLoadListener::OpenInParent instead of OpenDocument. Only OpenDocument called BounceTrackingState::OnStartNavigation, so for parent-initiated loads the BounceTrackingRecord was never created.
This affects two common real-world cases:
- Address bar / bookmark loads, which the parent initiates with the system principal.
- Content-initiated cross-site top level navigations, which under Fission switch process and are then initiated by the parent (
WindowGlobalParent::RecvLoadURI->OpenInParent), carrying the page's content principal.
Because the record is missing, BounceTrackingState::OnDocumentStartRequest and OnResponseReceived fail, and server-side bounces reached via these navigations are never classified as bounce trackers. This is the root cause behind the warnings investigated in bug 1894936:
WARNING: NS_ENSURE_TRUE(mBounceTrackingRecord) failed
WARNING: BounceTrackingState::OnDocumentStartRequest failed.
Bug 1913994 silenced the OnDocumentStartRequest warning as a stopgap while this underlying issue remained on file. The fix creates the record for parent-initiated loads (firing OnStartNavigation on the shared DocumentLoadListener::Open path, deduped by navigation load identifier) and restores that warning.
| Assignee | ||
Comment 1•15 days ago
|
||
Top level navigations initiated in the parent process go through
DocumentLoadListener::OpenInParent instead of OpenDocument. Only
OpenDocument called BounceTrackingState::OnStartNavigation, so for parent
initiated loads (address bar / bookmark loads with the system principal,
and content initiated cross-site navigations that process switch under
Fission) the BounceTrackingRecord was never created. As a result
OnDocumentStartRequest / OnResponseReceived failed and server side bounces
from these loads were never classified.
Move the OnStartNavigation call to the shared DocumentLoadListener::Open
path so it runs for both OpenDocument and OpenInParent, at navigation
initiation. A single logical navigation spans multiple
DocumentLoadListeners across process switches and speculative loads, so
dedupe the call at the BounceTrackingState layer using the navigation's
load identifier (nsDocShellLoadState::GetLoadIdentifier), which is stable
across those transitions but distinct per client side redirect hop.
Now that the record reliably exists, restore the OnDocumentStartRequest
and OnResponseReceived / OnDocumentLoaded warnings that were suppressed
for this bug.
The test observer for record-bounces now reports the number of classified
candidates so waitForRecordBounces can skip finalizations that classify
nothing, e.g. the empty extended navigation an activated initial page load
finalizes.
Comment 2•12 days ago
|
||
This is an automated duplicate detection tool. It suggests that this bug should be marked as a duplicate of Bug 1894936. The reasoning is: Both report BounceTrackingState::OnStartNavigation not being called for parent-initiated top-level loads (they route through DocumentLoadListener::OpenInParent, which never calls it), so no BounceTrackingRecord is created and the NS_ENSURE_TRUE(mBounceTrackingRecord) warning fires. Bug 2056952 identifies the concrete root cause behind the warnings investigated in bug 1894936. NOTE on direction: if the fix lands in bug 2056952, bug 1894936 should instead be closed as fixed-by / duplicate of bug 2056952.
Comment 5•9 days ago
|
||
| bugherder | ||
Description
•