213834 - TAB stop column not correct for <PRE> when image on the line

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Alexander Göransson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030724 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030724 Mozilla Firebird/0.6

@ http://www.neo-geo.com/mvs/mvs.html the prices listed should be a straight
list aligned after the first row. Now half of the prices are a bit off, henco
not displayingt proper lines.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Bill Mason]

This is not a Firebird specific bug.  Mozilla 2003072104 PC/WinXP has the same
rendering.
->Layout

Comment 2

[Boris Zbarsky [:bzbarsky]]

This needs a minimal testcase

Comment 3

[Boris Zbarsky [:bzbarsky]]

Actually, it just looks like the images are interfering with the wacky handling
of tabs in <pre> that we and IE do....  All the columns with an image are offset
to the right by a bit.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 5

[Anne (:annevk)]

In IE the columns are aligned ("like you would expect"), in Mozilla they are not.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So in Mozilla, tabs in a <pre> are effectively converted to spaces; the number
of spaces depends on the "number of chars seen so far" (mod 8).

Images don't really count as chars, of course.

A better question is what tabs should do, exactly, in this case.  Just advance
to the next "tab stop" from where they start?  But where are tab stops actually
placed?

Comment 7

[Hixie (not reading bugmail)]

I know this is somewhat unconventional, but we _could_ try doing what the spec
says we should do? Just an idea... :-)

# All tabs (U+0009) are rendered as a horizontal shift that lines up the start 
# edge of the next glyph with the next tab stop. Tab stops occur at points that 
# are mutiples of 8 times the width of a space (U+0020) rendered in the block's 
# font from the block's starting content edge.
 -- http://www.w3.org/TR/CSS21/text.html#q8

Comment 8

[Boris Zbarsky [:bzbarsky]]

We could try, but I'm not sure we have a computed position from the block's
content edge when we hit this code...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Of further note, even if we do know where we are in the block, the fact that we
can't just convert tabs to spaces means some interesting refactoring of the mess
that is text frame reflow is needed.

Comment 10

[Hixie (not reading bugmail)]

If it turns out to be too hard to implement that, then let me know what you
would like instead -- it's possible nobody yet implements the above and
therefore it would be "at risk" in terms of CSS2.1 exiting CR.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Well.... it _shouldn't_ be hard to implement, except it needs to be implemented
in code that's not very well written or documented....

Comment 12

[Daniel.S]

Looks like the issue has been fixed since the last comment, the textcase works fine across browsers and the problematic website uses a table now.

Comment 13

[Boris Zbarsky [:bzbarsky]]

This got fixed by the new textframe landing.

We should add a regression test for this.

Comment 14

[dolphinling]

Attachment: reftest - reference

Comment 15

[dolphinling]

Attachment: reftest - test

The test file includes a data url for a 1x1 white png, stretched to 10x4 for easier viewing of differences by a human.

Verified that they look the same (at least to my eye) in a current trunk build and definitely different in a pre-newtexframe build.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Pushed <http://hg.mozilla.org/mozilla-central/rev/2e386b2375e0>.  Thanks for the test!