Reduce Page Protection: Module allowing for temporary disabling tracking-protection for current tab
Categories
(Core :: Privacy: Anti-Tracking, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox150 | --- | fixed |
People
(Reporter: manuel, Assigned: manuel)
References
(Blocks 1 open bug)
Details
Attachments
(3 files, 1 obsolete file)
One pref for the start. Likely bound to the lifetime of the tab, so no persistent data necessary.
| Assignee | ||
Updated•6 months ago
|
| Assignee | ||
Comment 1•5 months ago
|
||
| Assignee | ||
Comment 2•5 months ago
|
||
Updated•5 months ago
|
Updated•5 months ago
|
| Assignee | ||
Updated•3 months ago
|
| Assignee | ||
Comment 3•2 months ago
|
||
Comment 5•2 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/a88c802fcdf4
https://hg.mozilla.org/mozilla-central/rev/a632f2b9b34b
Comment 7•2 months ago
|
||
Backed out for causing crashes [@ mozilla::dom::BrowsingContextWebProgress::BrowsingContextWebProgress ], e.g. bp-46278314-5f6b-4112-92c1-7ae290260303
Comment 8•2 months ago
|
||
The bug is linked to a topcrash signature, which matches the following criteria:
- Top 10 desktop browser crashes on nightly
- Top 10 AArch64 and ARM crashes on nightly
For more information, please visit BugBot documentation.
Updated•2 months ago
|
Updated•2 months ago
|
Comment 9•1 month ago
|
||
Attaching a reproducer for the Nightly crash. I generated it using Claude Code, socorro-cli and symdis. I'll share the Claude Code session internally for people who are curious. Below is the explanation for the crash, also generated by Claude Code.
Crash signature
[@ mozilla::dom::BrowsingContextWebProgress::BrowsingContextWebProgress]
172 crashes on Nightly 150.0a1 in under a day (March 3, 2026). Cross-platform
(Windows 82%, Linux 9%, Mac 9%). All parent process, main thread.
Root cause
The BrowsingContextWebProgress constructor unconditionally dereferences
Top()->GetWebProgress() for non-top BrowsingContexts:
// BrowsingContextWebProgress.cpp:50
mScopedPrefs = aBrowsingContext->Top()->GetWebProgress()->mScopedPrefs;
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// GetWebProgress() returns null here
GetWebProgress() returns the raw mWebProgress pointer from
CanonicalBrowsingContext. This is null when the top BC's mWebProgress has
been moved away by ReplacedBy() during a cross-site navigation.
How the crash happens
A cross-site navigation (e.g. example.com to example.org) with Fission
triggers a process switch. The parent process calls
CanonicalBrowsingContext::ReplacedBy(), which std::moves mWebProgress
from the old top BC to the new one (CanonicalBrowsingContext.cpp:255).
If the old content process has pending setTimeout callbacks (or other async
work) that create <iframe> elements, it sends CreateBrowsingContext IPC
messages to the parent. These messages arrive after ReplacedBy() has
already run. The parent handles them: Attach() creates a new
BrowsingContextWebProgress for the subframe. The constructor calls
Top(), which walks up the parent chain to the old top BC — the one
whose mWebProgress was moved to the new BC. GetWebProgress() returns null.
Null dereference at offset 0x98 (the offset of mScopedPrefs within
BrowsingContextWebProgress).
Content process (example.com) Parent process
-------------------------------- --------------------------------
setTimeout callbacks fire, Cross-site navigation starts
creating <iframe> elements (example.com -> example.org)
| |
v v
Each iframe creation sends ReplacedBy() runs:
CreateBrowsingContext IPC old top BC's mWebProgress is
to the parent std::move'd to new top BC
| |
+--- IPC messages arrive AFTER --------+
ReplacedBy() has run
|
v
Parent handles CreateBrowsingContext:
Attach() -> new BrowsingContextWebProgress(subframeBC)
Constructor: subframeBC->Top() returns OLD top BC
OLD top BC has mWebProgress == nullptr (moved away)
Top()->GetWebProgress()->mScopedPrefs <-- NULL DEREF
Reproducer
docshell/test/browser/browser_browsingContext_webprogress_subframe_crash.js
loads a page, schedules 15 setTimeout callbacks that each create an
<iframe>, then immediately navigates cross-site. The staggered timers
(0ms, 10ms, ..., 140ms) ensure some fire after ReplacedBy() has moved
mWebProgress, triggering the null dereference in the parent process.
To observe the crash in WinDbg (install from the Microsoft Store):
./mach mochitest --debugger=windbgx --debugger-args="-g -G -o" --headless docshell/test/browser/browser_browsingContext_webprogress_subframe_crash.js
Crash stack:
xul!nsCOMPtr<nsIScopedPrefs>::operator= [nsCOMPtr.h @ 563]
xul!mozilla::dom::BrowsingContextWebProgress::BrowsingContextWebProgress
[BrowsingContextWebProgress.cpp @ 50]
xul!mozilla::dom::BrowsingContext::Attach [BrowsingContext.cpp @ 1036]
xul!mozilla::dom::BrowsingContext::CreateFromIPC [BrowsingContext.cpp @ 640]
xul!mozilla::dom::ContentParent::RecvCreateBrowsingContext [ContentParent.cpp @ 6930]
Comment 10•1 month ago
|
||
| Assignee | ||
Comment 11•1 month ago
|
||
Thanks for helping me investigate. Was really useful :)
Comment 12•1 month ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/ac903b307883
https://hg.mozilla.org/mozilla-central/rev/7c80a3400303
Updated•1 month ago
|
Description
•