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

NEW
Unassigned

Status

()

P5
minor
11 years ago
6 years ago

People

(Reporter: jruderman, Unassigned)

Tracking

(Blocks: 3 bugs, {regression, testcase})

Trunk
x86
Mac OS X
regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9 -
wanted1.9 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
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).
(Reporter)

Comment 1

11 years ago
Created attachment 293904 [details]
testcase (with bounce)
(Reporter)

Comment 2

11 years ago
Created attachment 293905 [details]
reference (without bounce)
Probably a layout regression
Flags: blocking1.9?
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.
This testcase seems to work on branch.
Keywords: regression
Flags: blocking1.9? → blocking1.9+
Priority: -- → P5
Created attachment 296117 [details]
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...
> 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.
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...
Flags: wanted1.9+
Flags: blocking1.9-
Flags: blocking1.9+
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
You need to log in before you can comment on or make changes to this bug.