Make checks in nsDocShellLoadState DocShellLoadStateInit constructor not crash the parent
Categories
(Core :: IPC, enhancement)
Tracking
()
People
(Reporter: vhilla, Unassigned)
References
Details
nsDocShellLoadState::nsDocShellLoadState contains several sanity checks that use aActor->FatalError and crash the current process.
There have been false-positives and it would be nice if these could be more graceful. I.e. at least, we could only crash the sending process. Probably by not calling FatalError and rather keeping aReadSuccess=false while adding a crash annotation. Or we could consider changing the semantics of FatalError to do this more generally. We could also consider mimicking some checks in the sending process and have it stop the navigation rather than cause a content process crash.
See e.g. bug 2054485 or bug 2066354.
| Reporter | ||
Updated•1 month ago
|
Comment 1•13 days ago
|
||
I'm still experiencing this crash with Firefox 159.0 (64-bit) on Windows 11 (build 26300). The issue started with Firefox 157 and persists after reinstalling Firefox.
Crash details:
Illegal load attempt of file: URL from webMOZ_CRASH(IPC FatalError in the parent process!)- Stack trace:
nsDocShellLoadState::nsDocShellLoadState
What I've tested:
- A fresh Firefox profile works normally.
- Refreshing my existing profile temporarily fixes the crash.
- After closing and restarting Firefox, the crash returns, sometimes the next day.
- Troubleshoot Mode and disabling session restoration did not help.
- Disabling Firefox Sync and removing extensions initially helped.
- Manually reinstalling 1Password (8.12.41.1), including desktop integration, worked initially. However, the crash returned after reconnecting Firefox Sync.
Crash reports:
- Firefox 157.0:
bp-f079fc9f-d31d-460e-b9c3-c5e150261007 - Firefox 157.0.1:
bp-e9369e91-493f-46f0-8139-e0d280261011
A local Firefox 159.0 minidump from October 31 shows the same fatal error.
This seems related to Bug 2066354, despite its fixed status. I suspect an interaction between Firefox Sync, 1Password and the existing profile, but the root cause remains unconfirmed.
Could you investigate whether the fix also covers this scenario in Firefox 159.0?
Description
•