Open Bug 255139 Opened 20 years ago Updated 2 years ago

Reflow absolute children of relative positioned inlines during nsLineLayout::RelativePositionFrames


(Core :: Layout, defect, P3)





(Reporter: roc, Unassigned, NeedInfo)


(Blocks 10 open bugs)


(Whiteboard: [layout:backlog:quality])

Because horizontal alignment of inline frames can change their widths, absolute
children of relatively positioned inlines should be reflowed after horizontal
alignment. nsLineLayout::RelativePositionFrames would be a good place to do
this; we can't do it any later, because we need to compute the correct overflow
area in that method.

Also, if we do this, then line layout does not need to record the overflow area
of frames or spans in the per-frame or per-span structures, because all overflow
areas will be entirely computed on the fly in RelativePositionFrames. This will
save space and simplify code.

*** Bug 255138 has been marked as a duplicate of this bug. ***
See also bug 5016 comment 19 and following (though that's subsumed and
superceded by comment 0 here, I think).
Blocks: 5016
Assignee: roc → nobody
Flags: needinfo?(emilio)
No longer blocks: 1533151

Sean, given the amount of duplicates and dependent bugs, we should probably fix this sooner rather than later... WDYT? Should we prioritize fixing this?

Flags: needinfo?(svoisen)
See Also: → 489100

I'll bring this up at our triage meeting next week, but seems like we should.

Flags: needinfo?(svoisen)
Whiteboard: [layout:triage-discuss]
Priority: -- → P3
See Also: → 1536414

I don't think the suggested fix in the Summary is the right way
to implement this correctly. We need to reflow all continuations
of the CB before we can calculate the CB rectangle correctly.
Also, we should probably wait and see what the final resolution
is to this CSSWG issue is before starting this work.

There's a couple of comments from @bfgeek after the resolution
was noted, which seems to indicate they want to discuss it further,
or at least want clarifications. To me, your proposal there seems
to already handle block-axis fragments (the bit about negative
width/height) but perhaps they disagreed with it or didn't
understand it?

if there's lack of interop in a multicol context, then it's perhaps worth testing and proposing a solution to the group, but I wouldn't wait on the group to solve it. That said, for block-axis fragmentation, it seems like:
(a) multicol and printing should probably behave the same
(b) printing can't assume that the fragments are even in the same coordinate space
so I suspect block-axis fragmentation should think of the space prior to fragmentation rather than post-fragmentation.

See Also: → 1544146
See Also: 1544146
Whiteboard: [layout:triage-discuss] → [layout:backlog]
Whiteboard: [layout:backlog] → [layout:backlog:code-quality]
Whiteboard: [layout:backlog:code-quality] → [layout:backlog:quality]
See Also: → 1262910
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.