Closed Bug 1727431 Opened 3 months ago Closed 3 months ago

Replace GetCrossDocParentFrame in nsIFrame::GetOffsetToCrossDoc with GetCrossDocParentFrameInProcess

Categories

(Core :: Layout, task)

task

Tracking

()

RESOLVED FIXED
93 Branch
Fission Milestone MVP
Tracking Status
firefox-esr78 --- disabled
firefox-esr91 --- disabled
firefox91 --- disabled
firefox92 --- wontfix
firefox93 --- fixed

People

(Reporter: hiro, Assigned: hiro)

References

Details

(Whiteboard: fission-soft-blocker)

Attachments

(1 file)

No description provided.
Summary: eplace GetCrossDocParentFrame in nsIFrame::GetOffsetToCrossDoc with GetCrossDocParentFrameInProcess → Replace GetCrossDocParentFrame in nsIFrame::GetOffsetToCrossDoc with GetCrossDocParentFrameInProcess

GetOffsetToCrossDoc takes a valid non null pointer of nsIFrame, so it will not
walk up the frame tree across process boundaries.

If the call site needed the offset up to a frame in a different process, which
means the function call used for obtaining the nsIFrame needs to be audited such
as bug 1727229, which is for auditing GetReferenceFrame call sites
(GetOffsetToCrossDoc is often used with GetReferenceFrame, something like
GetOffsetToCrossDoc(GetReferenceFrame()).

FWIW, I did skim all GetOffsetToCrossDoc call sites [1], all look okay to me,
they are in auto scrolling, event handling, display list building, in the parent
process (i.e. XUL), etc. etc. Those features have been addressed in Fission.

[1] https://searchfox.org/mozilla-central/search?q=nsIFrame%3A%3AGetOffsetToCrossDoc&path=&case=true&regexp=false

Severity: -- → S3
Fission Milestone: --- → MVP
Whiteboard: fission-soft-blocker
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch
You need to log in before you can comment on or make changes to this bug.