298579 - inline boxes with negative width (e.g. from negative letter-spacing/word-spacing) are treated as width zero

Status: NEW

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

Description

[Hixie (not reading bugmail)]

STEPS TO REPRODUCE
1. Make letter-spacing be very negative.

ACTUAL RESULTS
   Text disappears.

EXPECTED RESULT
   Text renders, but backwards.

TESTCASE
   http://bugzilla.opendarwin.org/attachment.cgi?id=2580

This bug derived from webkit bug number 3676.
   http://bugzilla.opendarwin.org/show_bug.cgi?id=3676

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase

Bug also occurs with negative 'word-spacing'

Comment 2

[Mats Palmgren (inactive)]

Attachment: Screenshot #1

I'm a bit curious what the correct rendering would be - does this screenshot
look correct to you?

Comment 3

[Hixie (not reading bugmail)]

Yeah, that seems roughly correct.

Comment 4

[Hixie (not reading bugmail)]

dbaron: Do you agree this bug is valid?

Comment 5

[Robin Whittleton]

Fixing this would break MIR image replacement.

http://www.stuffandnonsense.co.uk/archives/mir_image_replacement.html

Comment 6

[Robin Whittleton]

Sorry, just read the webkit bug linked in the original report - ignore me.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Ian, can we add some tests for this to the CSS2.1 test suite just to make sure this edge case is done interoperably?

Comment 8

[Jesse Ruderman]

This testcase triggers an assertion (see bug 334107) :

###!!! ASSERTION: bad width: 'metrics.width>=0', file
/Users/admin/trunk/mozilla/layout/generic/nsLineLayout.cpp, line 1069

Comment 9

[Boris Zbarsky [:bzbarsky]]

We should really fix this, imo.  Esp. if us not fixing it is cause for Safari to start breaking the spec...

Comment 10

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

We should fix it, but it might be very hard because we don't really support negative-width frames. Maybe we can do it by getting the right overflow area and then finding a way to get a negative X-advance reported to nsLineLayout.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Yeah, that's what I was more or less thinking...

Comment 12

[Mats Palmgren (inactive)]

http://bugzilla.opendarwin.org/ seems to have moved to http://bugs.webkit.org
so the links in comment 0 are now:
Testcase:    http://bugs.webkit.org/attachment.cgi?id=2580
Webkit bug:  http://bugs.webkit.org/show_bug.cgi?id=3676

Comment 13

[Mats Palmgren (inactive)]

The current layout is very close to that of Safari 3.0.4, so the
layout is much improved compared to Firefox 2.
We still set the box height to zero in some cases though.
I don't see the assertion in comment 8 on either testcase.

Comment 14

[Zack Weinberg (:zwol)]

Attachment: test case #2 (simpler)

I have a simpler test case for this bug.  There are two lines, which should be rendered nearly identically (the inter-glyph spacing may not be exactly the same).  Instead, the top line is rendered with groups of three numbers painted on top of each other.

This highlights what's actually going wrong here: when an inline box (== layout frame, probably) has negative width, the next box is placed as if the negative-width box had had width zero.  I think this is what roc is getting at in comment 10 when he says "we don't really support negative-width frames."

Comment 15

[kcarchana77]

I am interested to work on this bug and I would I like to know more details about this bug. I would also like to know where I should get started.