Crash in [@ nsGlobalWindowInner::StorageAccessGranted]
Categories
(Core :: Privacy: Anti-Tracking, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox75 | --- | unaffected |
| firefox76 | --- | unaffected |
| firefox77 | --- | fixed |
| firefox78 | --- | fixed |
People
(Reporter: gsvelto, Assigned: dimi)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
|
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
This bug is for crash report bp-a18b3a1d-63f9-4bfb-bb97-f422c0200503.
Top 10 frames of crashing thread:
0 xul.dll nsGlobalWindowInner::StorageAccessGranted dom/base/nsGlobalWindowInner.cpp:7202
1 xul.dll static mozilla::ContentBlocking::OnAllowAccessFor toolkit/components/antitracking/ContentBlocking.cpp:567
2 xul.dll mozilla::ContentBlocking::AllowAccessFor::<unnamed-tag>::operator const toolkit/components/antitracking/ContentBlocking.cpp:363
3 xul.dll mozilla::MozPromise<mozilla::Maybe<mozilla::ContentBlocking::StorageAccessPromptChoices>, mozilla::ipc::ResponseRejectReason, 1>::ThenValue<`lambda at /builds/worker/checkouts/gecko/toolkit/components/antitracking/ContentBlocking.cpp:354:14'>::DoResolveOrRejectInternal xpcom/threads/MozPromise.h:798
4 xul.dll mozilla::MozPromise<CopyableTArray<bool>, nsresult, 0>::ThenValueBase::ResolveOrRejectRunnable::Run xpcom/threads/MozPromise.h:405
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1200
6 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:481
7 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:87
8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308
9 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
This looks like a a dereference of a NULL this pointer. The oldest buildid for this crash is 20200429215539. Tentatively filing under Core > Privacy: Anti-Tracking because most of the changes around this code seem to be happening in this component. Please move to the right component if this is wrong.
| Assignee | ||
Updated•5 years ago
|
| Assignee | ||
Comment 1•5 years ago
|
||
We keep the reference of BrowsingContext across IPC call. But the
BrowsingContext may be discarded when returning from the IPC call.
This crash happens when:
A first-party window calls window.open(a 3rd-party url), which triggers
the storage access heuristic, and then the window is closed
immediatelly.
This patch fixes this issue by checking IsDiscard() when returning from
the IPC call.
Comment 3•5 years ago
|
||
| bugherder | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 4•5 years ago
|
||
There was no crash in the last 3 nightly builds with the patch, Dimi do you want to request an uplift to beta?
| Assignee | ||
Comment 5•5 years ago
|
||
Comment on attachment 9145733 [details]
Bug 1635020 - Check whether browsing context is discarded after returning from an IPC call r=timhuang
Beta/Release Uplift Approval Request
- User impact if declined: may crash if a 3rd-party tracker's iframe opens a window and then the iframes'window is immediately closed.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This change only check if browsing context is discarded before continuing
- String changes made/needed:
Comment 6•5 years ago
|
||
Comment on attachment 9145733 [details]
Bug 1635020 - Check whether browsing context is discarded after returning from an IPC call r=timhuang
Simple null check crash fix. Approved for 77.0b3.
Comment 7•5 years ago
|
||
| bugherder uplift | ||
| Comment hidden (Intermittent Failures Robot) |
Updated•5 years ago
|
Description
•