Open Bug 605041 Opened 14 years ago Updated 2 years ago

inconsistency between immediate breaking and backtracked breaking

Categories

(Core :: Layout: Text and Fonts, defect)

defect

Tracking

()

People

(Reporter: dbaron, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: css2)

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).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.