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

Status: NEW

(Core :: Layout, defect, P3)

Description

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

See http://bugzilla.mozilla.org/show_bug.cgi?id=252771#c6

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

*** Bug 255138 has been marked as a duplicate of this bug. ***

Comment 2

[Boris Zbarsky [:bzbarsky]]

See also bug 5016 comment 19 and following (though that's subsumed and
superceded by comment 0 here, I think).

Comment 3

[Emilio Cobos Álvarez (:emilio)]

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

Comment 4

[Sean Voisen (:svoisen)]

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

Comment 5

[Mats Palmgren (inactive)]

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.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

https://github.com/w3c/csswg-drafts/issues/609 seems to me to be sufficiently resolved.

Comment 7

[Mats Palmgren (inactive)]

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?

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.