2059768 - Add tests for BounceTrackingProtection under per-site container association

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, task)

Description

[Emma Zühlcke [:emz]]

Bug 2052136 adds per-site container associations: a top level navigation to a site bound to a container is retargeted into a new tab in that container (pref privacy.containers.switchDuringNavigation.enabled).

That retarget splits one extended navigation across two tabs, and therefore across two BounceTrackingStates and two per-container stores. The record stays with the tab the load started in and is filed under that tab's OriginAttributes, while the load commits in another container. Bug 2054941 investigated this; Bug 2058145 tracks the fix.

This bug is for landing the tests that pin the current behaviour, so the fix in Bug 2058145 has something to flip. The new file is toolkit/components/antitracking/bouncetrackingprotection/test/browser/browser_bouncetracking_siteContainer.js. It covers:

• A bounce chain whose destination is bound, client and server side. With a client side bounce the tracker commits its own document, becomes the record's final host and is skipped, while the destination is classified in its place.
• A bound tracker followed by an unbound destination, which is not retargeted at all: the tracker's hop runs in the bound container while the classification is filed against the container the chain ran in, so the purge cannot reach its state.
• A bound tracker retargeted into its own container, where it is the initial host of the new tab's record and therefore exempt.
• An ordinary navigation to a bound site, including from a blank tab which the retarget closes, which classifies the site in the container navigated from.
• User activation on the retargeted document, which lands in the other store and so cannot lift the classification.
• A purge deleting first party and partitioned third party state in the container navigated from, and a host association reaching the whole eTLD+1.
• A site open in a retargeted tab, which the active site purge guard does not see because such a tab has no BounceTrackingState.

Two tasks are controls: a site bound to the container its tab is already in, and the feature pref disabled. Both behave exactly as they do without the feature.

Expectations that describe the behaviour BTP needs but does not currently get are marked with todo(), so the file is green today and the assertions become real when Bug 2058145 lands.

The tests rely on Bug 2056952, which moved BounceTrackingState::OnStartNavigation to the shared DocumentLoadListener::Open path, so a record exists for parent initiated loads too.

Comment 1

[Emma Zühlcke [:emz]]

Attachment: Bug 2059768 - Add tests for BounceTrackingProtection under per-site container association. r=baku!

Bug 2052136 retargets a top level navigation to a site bound to a container into
a new tab in that container. This splits one extended navigation across two
tabs, and so across two BounceTrackingStates and two per-container stores: the
record stays with the tab the load started in and is filed under that tab's
OriginAttributes, while the load commits in another container.

The fix, which turns the todo() expectations into real assertions, is
tracked in Bug 2058145.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/665ee94a7372
https://hg.mozilla.org/integration/autoland/rev/ed1e8d795aa6
Add tests for BounceTrackingProtection under per-site container association. r=baku,timhuang

Comment 3

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/ed1e8d795aa6