Open Bug 2080238 Opened 1 month ago Updated 13 days ago

Make checks in nsDocShellLoadState DocShellLoadStateInit constructor not crash the parent

Categories

(Core :: IPC, enhancement)

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.

Severity: -- → N/A
See Also: → 2054485, 2066354

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 web
  • MOZ_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?

You need to log in before you can comment on or make changes to this bug.