Abel Lin(alin, abel) Reporter
	Description • 11 years ago

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

	Abel Lin(alin, abel) Reporter
	Comment 1 • 11 years ago

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?

	:kip (Kearwood Gilbert) Assignee
	Comment 2 • 11 years ago

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?

	Abel Lin(alin, abel) Reporter
	Comment 3 • 11 years ago

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

	:kip (Kearwood Gilbert) Assignee
	Comment 4 • 11 years ago

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

	Corey Ford [:coyotebush]
	Comment 5 • 11 years ago

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.

	Corey Ford [:coyotebush]
	Comment 6 • 11 years ago

Didn't mean to close it myself, though.

	David Baron :dbaron:
	Comment 7 • 11 years ago

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

	:kip (Kearwood Gilbert) Assignee
	Comment 8 • 11 years ago

Closing as the issue can no longer be reproduced