Make nsFrameManager::CaptureFrameState robust against nsPlaceholderFrames that have a null out-of-flow frame
Categories
(Core :: Layout, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox142 | --- | fixed |
People
(Reporter: dholbert, Assigned: dholbert)
References
Details
Attachments
(1 file)
Bug 1758205 is a case where we're calling nsFrameManager::CaptureFrameState
to save frame-state (scroll positions, etc.) in sessionhistory, and we trip over a placeholder frame that has a null out-of-flow frame, and we crash.
Placeholders aren't supposed to have null out-of-flow frames, but we've got edge cases where it's known to happen (going back to e.g. bug 1429172 at least, "Null out-of-flow for placeholder?" assertion there). So let's make nsFrameManager::CaptureFrameState
handle this a little more gracefully rather than crashing.
Assignee | ||
Comment 1•2 months ago
|
||
As noted in the code-comment, it theoretically shouldn't be possible for a
placeholder frame to have a null out-of-flow pointer; but we have fuzz tests
(like the included one) that do trigger this situation. Instead of crashing,
let's handle these gracefully and just skip the recursive-call when we
encounter nullptr.
Skipping the rercursive call isn't too terrible; it just means we won't be able
to record mutable state like scroll positions for the unreachable out-of-flow
subtree, in testcases that trip over this edge case. Affected frames will just
be at their default state (e.g. scrolled to the start) when we session-restore
them or clone them for printing.
I'm including a crashtest based on bug 1758205's testcase (that's the
fuzzblocker that I'm aiming to mitigate here). That crashtest still fatally
asserts in debug builds (with the assertion that bug 1427833 is about), so I've
annotated to be skipped in debug builds. In opt builds, though, this patch
should allow the crashtest to proceed instead of crashing with a
null-defererence.
Updated•2 months ago
|
Updated•2 months ago
|
Description
•