inconsistency between immediate breaking and backtracked breaking

NEW
Unassigned

Status

()

Core
Layout: Text
7 years ago
a year ago

People

(Reporter: dbaron, Unassigned)

Tracking

(Blocks: 1 bug, {css2})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
We fail these tests (all identical):
http://test.csswg.org/suites/css2.1/20101001/html4/white-space-mixed-001.htm
http://test.csswg.org/suites/css2.1/20101001/xhtml1/white-space-mixed-001.xht
http://www.hixie.ch/tests/adhoc/css/text/white-space/mixed/001.html

I'm not sure if the tests are valid (also see bug 191699 comment 17, etc.).  However, I'm pretty sure they demonstrate a bug in our code, for the following reasons:

The reason we fail is that we're breaking in the middle of the 4th of the 7 lines in the test (with "PASS" on lines 3-7).  If I make the following change to the test, we start passing:

--- white-space-mixed-001.htm      2010-10-17 14:42:42.000000000 -0700
+++ white-space-mixed-001.htm   2010-10-17 14:42:45.000000000 -0700
@@ -30,7 +30,7 @@
 xxxx </span> </span>x<span class="normal"> <span class="pre"> </span> <span
class="pre"> </span> <span class="pre"> </span>
 <span class="nowrap">
  </span> </span>  <span class="pre"> </span><span class="normal"> </span>
<span class="nowrap">
- </span><span class="normal"> </span>  x x  x x  x x    x
+ </span><span class="nowrap"> </span>  x x  x x  x x    x
 <span class="nowrap">x
 x x x x x x x x x xxxx
 xxxx xxxx xxxx </span>

This forces that fourth line back together.

However, if I *additionally* change the space that allows a break between lines 3 and 4 to a "z":

-xxxx </span> </span>x<span class="normal"> <span class="pre"> </span> <span class="pre"> </span> <span class="pre"> </span>
+xxxx </span>z</span>x<span class="normal"> <span class="pre"> </span> <span class="pre"> </span> <span class="pre"> </span>

then I'd have expected that to put lines (3) and (4) (both previously wider than their container) together.  However, it doesn't; instead we get a new (earlier) breakpoint.

This demonstrates an inconsistency between the break points to which we backtrack and the break points that we use when we're over width (or going to be over width by placing the next frame).

I *think* the test is asserting that the first set is correct and we have too many potential breakpoints in the second set.  I'm not sure if that assertion is correct (though it is compatible with WebKit, since WebKit passes).
(Reporter)

Updated

7 years ago
Blocks: 605520
You need to log in before you can comment on or make changes to this bug.