22913 - word wrap off on page with code sample

Status: VERIFIED DUPLICATE of bug 54834

(Core :: Layout, defect, P2)

Description

[jr]

using latest nightly build (1-2-2000) on a RH6.1 box, the above URL looks
terrible esp. compared to N4. not sure if this a gecko bug or not, but i hope
this helps.

Comment 1

[troy]

May be a style problem. Someone needs to reduce it to a smaller test case. Block
issue so re-assigning to Kipp's bug list

Comment 2

[buster]

I am about to attach a minimized test case.  It looks like in Nav the blockquote
is basing it's width on the containing table's width attribute, and not the
actual computed width of the table.

Comment 3

[buster]

Attachment: small test case

Comment 4

[buster]

at least part of this is a parser problem.  Look at the second attachment (that
I am about to add.)  It does not lay out correctly.  Worse, it lays out
differently in viewer and mozilla. Maybe a default compatibility mode thing?  If
you remove the comments in the (second) test case so there is an </P> in the
content, it works better, but still different in the two gecko clients.

Comment 5

[buster]

Attachment: parser test case

Comment 6

[buster]

assigning to rickg to handle the parser related problems.  when they're fixed, 
reassign to me for the layout issues.

Comment 7

[buster]

I am about to attach images of what I see in debug builds of viewer and mozilla.  
Today's optimized build does NOT show this difference:  both optimized viewer 
and optimized mozilla have the no word wrap behavior.

Comment 8

[buster]

Attachment: viewer, showing wrapped lines

Comment 9

[buster]

Attachment: mozilla, showing unwrapped lines

Comment 10

[buster]

Attachment: from mozilla browser, broken content model, pre contains blockquote

Comment 11

[buster]

Attachment: viewer, correct content model, pre and blockquote are siblings

Comment 12

[buster]

harish:  I've attached both screen shots and content model dumps of the 
difference.  I'd look at both problems (assuming you can reproduce!), the broken 
content model as shown by mozilla, and the difference between mozilla and viewer 
is scary as well.  Could it be an uninitialized variable?  Purify might help.

Comment 13

[harishd]

Attachment: What I see in mozilla.

Comment 14

[harishd]

Attachment: What I see in viewer

Comment 15

[buster]

(1) our different experiences lead me to believe there's an uninitialized 
variable somewhere
(2) at least you can reproduce the incorrect content model case at will, so you 
should be able to track that down at least.

Comment 16

[harishd]

The problem is PRE being allowed to contain flow-entities ( block & inline ). 
Per spec. PRE should contain nothing but inline.

Comment 17

[harishd]

Assuming it's mine.

Comment 18

[harishd]

Forgot to mark "Reassign but to" field.

Comment 19

[harishd]

Made BLOCKQUOTE to not be contained withing PRE ( as per spec. )
FIXED.

Comment 20

[Chris Petersen]

Fixed in the Feb 18th build (2000021808).

Comment 21

[rickg]

This is wrong as far a backward compatibility is concerned. Given Buster's 
testcases, we look the same as IE. And the fix you added here causes bug 53473. 
Reopening.

Comment 22

[rickg]

It turns out that the real bug here isn't that <PRE> can't contain <BLOCKQUOTE> 
(which is true per spec but not in practice), but that the <PRE><P></PRE> wasn't 
being allowed to close. It does now as a sideeffect of fixing bug 54834.

I'm marking this a dup of that bug.

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

Comment 23

[timeless]

vrfy dupe. However according to bugzilla bug 54834 is not fixed. [See also dupe 
bug 61077]