212854 - complex constructed 'picture' rendered wrong

Status: RESOLVED DUPLICATE of bug 196270

(Core :: CSS Parsing and Computation, defect)

Description

[harm]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

The url points to a browser stress test site.
The problem is that the picture that is constructed on this url is not rendered
correctly in mozilla.
IE 6.0 does this correct.  (IE is however much slower than mozilla...)

note: the url is about browser performance/stressing. This bug is not about this.

Reproducible: Always

Steps to Reproduce:
1. click url (400kbyte html file)
2. view the (slowly constructed) 'picture' of a cat.


Actual Results:  
The picture of the cat has white lines every other pixel.

Expected Results:  
The picture appears without white lines.  (like IE 6.0 does)

Comment 1

[Boris Zbarsky [:bzbarsky]]

No lines visible with linux trunk build 2003-07-16-05.

Over to something like the right component.

Comment 2

[Bill Mason]

WFM 20030710 PC/WinXP

Comment 3

[Mats Palmgren (inactive)]

The problem is the specified CSS font:  "font: 1px/1 Ahem;"
Changing this to "font: 1px/1px Ahem;" makes it render as expected.
It's a Quirk mode page and I think we accept lengths without a unit in this mode,
so maybe we should here too?
"font: 1/1px Ahem;" also works for example.

-> Style System

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

numbers are valid for 'line-height'.

*** This bug has been marked as a duplicate of 196270 ***

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(I don't see the problem on Linux, either, though, so maybe it shouldn't be a
duplicate.)

Comment 6

[Mats Palmgren (inactive)]

Attachment: Screenshot with 1px/1

I think this might be dependent on what font the X server gives you...

This is what I see on 2003-07-14-22 trunk Linux.

Comment 7

[Mats Palmgren (inactive)]

Attachment: Screenshot with 1px/1 (detail at 400%)

Comment 8

[Mats Palmgren (inactive)]

Attachment: Screenshot with 1px/1px

It looks a bit stretched, right?

Comment 9

[Mats Palmgren (inactive)]

When I set GECKO_USE_COMPUTED_HEIGHT the 1px/1 case renders them same as 1px/1px,
so I guess it is a duplicate after all?

Comment 10

[Aiko]

The testcase at the URL looks completly broken in Deer Park Alpha 2 and
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050817
Firefox/1.6a1. I don't think the current behavior is related to line-height.

Comment 11

[Mats Palmgren (inactive)]

(In reply to comment #10)
It's because we start ignoring stuff as we reach a certain tag depth (bug 58917 /
bug 256180), so the current rendering is intentional.

Comment 12

[Mats Palmgren (inactive)]

Attachment: Screenshot

As a test I took dbaron's patch for bug 196270 and then changed
MAX_REFLOW_DEPTH to huge value and this is the result.
It shows that Gecko would render this evil testcase correctly if we let it run
with unconstrained tag depth, however this could cause crashes/hangs on some
hosts. To give you an idea: it took over 3 hours to render this page (reaching
a maximum reflow depth of 18085) on a 3GHz P4 running at 100% CPU and the
process memory usage was ~150MB when finished.

Comment 13

[Aiko]

Attachment: Screenshot from 1.8a6

(Just for fun. Yes, that is at 100% text size...)

Thanks for the info, quite interesting. It's just a bit baffling that in
earlier Mozilla versions the cat was at least recognizable and displayed in a
reasonable amount of time. Now I get nothing more than an ugly-colored
rectangle, let's hope fixing bug 256180 brings an improvement.

Comment 14

[harm]

I see that in firefox 2.0.0.3 the URL does again not render correctly.

on windows XP (dell laptop) the 'cat' renders as an opaque grey block.
Should this be reopened?

Comment 15

[Mats Palmgren (inactive)]

The remaining issue is covered by bug 256180 I think. (see comment 10/11/12)