409065 - Inconsistent rendering with position:absolute, white-space:pre

Status: NEW

(Core :: Layout, defect, P5)

Description

[Jesse Ruderman]

The testcase and reference are identical except for a "bounce", but the 'x' doesn't appear in the same place in both files.

They are based on layout/base/crashtests/310638-2.html (from bug 310638).

Comment 1

[Jesse Ruderman]

Attachment: testcase (with bounce)

Comment 2

[Jesse Ruderman]

Attachment: reference (without bounce)

Comment 3

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

Probably a layout regression

Comment 4

[Boris Zbarsky [:bzbarsky]]

For what it's worth, reloading the reference from cache shows the same behavior as the testcase...  Perhaps a reference that dynamically toggles the abs pos frame to be shown or something would reproduce reliably?

In any case, I bet the issue is this comment in nsHTMLReflowState::CalculateHypotheticalBox:

927 // XXXbz the placeholder is not fully reflown yet if our containing block is
928 // relatively positioned...

since we're hitting the auto-offset situation here.

Comment 5

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

This testcase seems to work on branch.

Comment 6

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

Attachment: slightly more focused testcase

This testcase just creates a frame for the innermost abs-pos span, this is enough to show the bug.

I think the basic problem here is that we reflow the rel-pos span's first in flow and reflow its abs-pos child before we reflow the rel-pos span's next in flow which contains the placeholder for the abs-pos child, so we don't have a correct position for the placeholder (in fact we haven't reflowed the placeholder at all).

I'm not sure what to do about this. I suppose the best thing to do would be to delay reflowing the abs-pos children of the primary frame until we've reflowed the *last* continuation of the span. But that's seriously difficult/wrong given that the last continuation might be being reflowed by a different containing block continuation and the overflow areas for the primary frame and its ancestors will already have been set.

I'll think about this some more but basically I think this is a case which our layout architecture just doesn't handle. Maybe we can just detect it and issue a post-reflow callback to reflow the abs-pos frame again. Bah...

Comment 7

[Boris Zbarsky [:bzbarsky]]

> I suppose the best thing to do would be to delay reflowing the abs-pos
> children of the primary frame until we've reflowed the *last* continuation of
> the span

Technically, the spec actually requires this, since the containing block depends on the final size and position of the last-in-flow.  We don't implement that, clearly...

I'm not sure this is worth worrying about much, esp. in the 1.9 timeframe.

Comment 8

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

Yeah. I'll make this "wanted".

A similar problem could arise with rel-pos blocks or tables splitting vertically. This actually has pretty huge implications for how layout should work. You need to be able to break content across pages and then go back and reflow abs-pos frames in pages you've already "finished". We just can't support that today because of overflow area calculation and other issues.

Oh well, this informs my thoughts about redesigning layout...