Closed Bug 896548 Opened 6 years ago Closed 6 years ago
Investigate impact of sticky positioning offsets on Computed
http://mxr.mozilla.org/mozilla-central/ident?i=GetRelativeOffset&tree=mozilla-central&strict=1 The results of nsHTMLReflowState::ComputeRelativeOffsets get stored in the frame's ComputedOffsetProperty, which is accessible through nsIFrame::GetRelativeOffset. This is used to adjust the position of various things, seemingly only ever in one dimension or the other. Sticky positioning offsets from bug 886646 will also be stored in nsHTMLReflowState::mComputedOffsets (but should be interpreted differently), so either a) I need to adjust users of the frame property (following bug 893962), or a) sticky offsets simply shouldn't be stored in the frame property.
Most importantly, we presumably would like to support sticky positioned floats, so the three float-related uses of ComputedOffsetProperty (in nsBlockFrame, nsBlockReflowState, and nsFloatManager) would need to be adjusted to involve nsHTMLReflowState::ApplyRelativePositioning somehow. I'm realizing it might be nice to store computed sticky offsets in a frame property, but not sure it's worth affecting all the other uses (which as it happens mostly care about only one of .x and .y).
What I'll probably end up doing is * store sticky offsets in a separate frame property * store the "normal" position before relative/sticky positioning in yet another frame property, and replace the uses of |GetPosition() - GetRelativeOffset()| with |GetNormalPosition()|. * use ApplyRelativePositioning to enable sticky positioning of floats
With bug 898794 and bug 898797 filed, I think I'm done ruminating here.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.