983523 - position:sticky Last continuation got a wrong offset when calculating margine union

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Abel Lin(alin, abel)]

The bug is continued from Bug 980247 comment 13 ~ 23.

Comment 1

[Abel Lin(alin, abel)]

update what I found.

(1)
The wrong margin union resulted from wrong position of last element, which make the StickyScrollContainer::ComputePosition calculated wrong position(max and mix).

(2)
However, the wrong position of last element wasn't updated. But why first element could be updated?
They both are inline block, one was updated and the other wasn't.

(3)
From log, I found the point is in nsBlockFrame::PrepareResizeReflow. The function will 
try to set dirty flag to children before invoking StickyScrollContainer::PositionContinuations.
First element was set, but the last element wansn't set. So the states in nsBlockFrame::PrepareResizeReflow between first inline element and last inline element are as below:

first -> isLastLine: false; HasBreakAfter = false; IsLineWrapped = false; skipLastLine = true;
last -> isLastLine: true; HasBreakAfter = false; IsLineWrapped = false; skipLastLine = true;

The first element set resulted from condition (!isLastLine && !line->HasBreakAfter()); however,
The last element didn't match any conditions. If skipLastLine is true, last element would match
the condition((isLastLine || !line->IsLineWrapped()) && !skipLastLine)).

I'm not if the state is correct.
The symptom is gone if last element is forced to set dirty in nsBlockFrame::PrepareResizeReflow.

So is there something wrong in nsBlockFrame::PrepareResizeReflow?

Comment 2

[:kip (Kearwood Gilbert)]

Running block-in-inline-3.html no longer appears to give the same results shown in Bug 980247 attachment 8389759 [details] (normal.mp4).

Is there another way to illustrate the problem?

Comment 3

[Abel Lin(alin, abel)]

I tried some ways. But It cannot be reproduced so far. :(

Comment 4

[:kip (Kearwood Gilbert)]

Can this bug be closed as "Can Not Reproduce"?

Comment 5

[Corey Ford [:coyotebush]]

I think there could still be something wrong regarding position/normal-position as I observed in bug 980247 comment 21, the effects of which were covered up by the patch in that bug. But perhaps it's not really a bug if we can't illustrate it anymore.

Comment 6

[Corey Ford [:coyotebush]]

Didn't mean to close it myself, though.

Comment 7

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

I'm fine with closing this; I'm not sure what there was here that wasn't fixed in bug 980247.

Comment 8

[:kip (Kearwood Gilbert)]

Closing as the issue can no longer be reproduced