141021 - text is diplayed over the right border

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect, P2)

Description

[Eugen]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc1)
Gecko/20020417
BuildID:    2002041711

The following title " In Office-Dateien steckt mehr als nur der reine
Dokumenteninhalt. Wer Daten austauscht, kann so unwissentlich heikle
Zusatzinformationen weitergeben. Wir erklären, wie Sie das Risiko minimieren."
in the page at http://www.tecchannel.de/software/896/index.html is not displayed
as a block, like the test below. It goes over the right border of thhe site.

In IE this title is displayed as a block, so it is readable.

Reproducible: Always
Steps to Reproduce:
1.goto http://www.tecchannel.de/software/896/index.html
2. look on the title of the article right to the msoffice-picture


Actual Results:  text is diplayed over the right border of the site

Expected Results:  text should be formated as a block

Comment 1

[Chris Waterson]

Attachment: out-of-line script

Comment 2

[Chris Waterson]

Attachment: minimized test case (relies on out-of-line script, above)

Comment 3

[Chris Waterson]

Argh. The test case above (attachment 81575 [details]) seems to bomb when I load it
locally, but not when I load it from bugzilla. The inline scripts make be
believe it's some sort of table incremental reflow problem.

Comment 4

[Chris Waterson]

Attachment: out-of-line script.

Comment 5

[Chris Waterson]

Attachment: minimized test case, relies on out-of-line script, above

This test case works a bit more reliably: you may have to reload a few times to
reproduce the bug, so it's best if you can save the stuff locally.

Comment 6

[Chris Waterson]

Attachment: more minimal

Got rid of a few tables. The problem appears to be that the fixed-width cell is
flowing its contents at an unconstrained width, and then never reflowing them
again:

		...
		 tblO 0x82c587c r=0 a=UC,UC c=0,0 cnt=50 
		  tbl 0x82c5a50 r=0 a=UC,UC c=8341,UC cnt=51 
		   rowG 0x82c5b30 r=0 a=UC,UC c=UC,UC cnt=52 
		    row 0x82c5bdc r=0 a=UC,UC c=UC,UC cnt=53 
		     cell 0x82c5cf4 r=0 a=UC,UC c=8341,UC cnt=54 
		      block 0x82c5d54 r=0 a=UC,UC c=UC,UC cnt=55 
		       text 0x82c5e0c r=0 a=UC,UC c=UC,UC cnt=56 
		       text 0x82c5e0c d=25042,323 me=2603 
		      block 0x82c5d54 d=24966,323 me=2603 
		     cell 0x82c5cf4 d=25080,437 me=2717 
		    row 0x82c5bdc d=UC,437 
		   rowG 0x82c5b30 d=UC,437 
		   colG 0x82c5eb0 r=0 a=UC,UC c=UC,UC cnt=57 
		    col 0x82c5f24 r=0 a=0,0 c=8341,UC cnt=58 
		    col 0x82c5f24 d=0,0 
		   colG 0x82c5eb0 d=0,0 
		  tbl 0x82c5a50 d=8341,437 me=8341 
		 tblO 0x82c587c d=8341,437 me=8341 
		...

karnaze: why wouldn't it set the available width to be 8341 twips, too?

Comment 7

[Chris Waterson]

-> HTML tables. I'll let the pros handle this. :-)

Comment 8

[Chris Waterson]

karnaze: to reliably reproduce this bug, save attachment 81602 [details] and attachment
81557 [details] [diff] [review] locally. You'll need to fix the HTML file so that it properly refers to
the out-of-line JavaScript.

Comment 9

[Eugen]

If i load <a HREF="showattachment.cgi?attach_id=81602">attachment 81602 [details]</a> the
text stays inside the table. But if i go back in history and go forward again to
the testpage, the text goes over the right border.

Comment 10

[Chris Waterson]

The patch in bug 120107 appears to fix this.

Comment 11

[karnaze (gone)]

Taking the bug. I'll be attaching a patch, since the revised patch in bug 120107 
does not fix this.

Comment 12

[karnaze (gone)]

Attachment: patch to fix the bug

Comment 13

[karnaze (gone)]

Attachment: patch to fix the bug (ignore the previous one)

Comment 14

[karnaze (gone)]

Attachment: revised patch

Comment 15

[Bernd]

Comment on attachment 82630 [details] [diff] [review]
revised patch

r=bernd

Chris could you please update the comment above the reflow optimization in
nsTableRowGroupFrame.cpp.

Comment 16

[Chris Waterson]

Comment on attachment 82630 [details] [diff] [review]
revised patch

sr=waterson

Comment 17

[Chris Waterson]

Comment on attachment 82630 [details] [diff] [review]
revised patch

sr=waterson

Comment 18

[karnaze (gone)]

FIXED_ON_TRUNK

Comment 19

[Katsuhiko Momoi]

Nominating for nsbeta1 and topembed. Needed for a bank customer
in Japan.

Comment 20

[Katsuhiko Momoi]

Can we check this into 1.0.2 branch?

Comment 21

[karnaze (gone)]

I think the risk of this patch for the m1.0 branch is low because (1) it has
been on the trunk since 5/9/2, (2) it passes all of the regression tests on the
branch, (3) the patch added a needed reflow to fix the bug, so probably in the
worst case (and this assumes that the patch is not correct in general), a page
might get an extra reflow.

Comment 22

[Jaime Rodriguez, Jr.]

Marking as nsbeta1+/topembed+ as this is effecting a major bank site in Japan.
Nominating for 1.0 branch.

amar: can you pls verify this as fixed on the trunk? thanks!

Comment 23

[robinf]

Per adt, please verify on trunk for adt approval.

Comment 24

[Amarendra Hanumanula]

Verified on todays trunk builds: 2002-10-27-08-trunk builds on Win2K and 
Linux7.1. The given URL and the testcases work fine. We can check the patch into 
the 1.0.2 branch.

Comment 25

[Katsuhiko Momoi]

Per amar's comment #24, this bug is now verified as dixed.

Comment 26

[chris hofmann]

Comment on attachment 82630 [details] [diff] [review]
revised patch

a=chofmann for 1.0.2

Comment 27

[Michael Buckland]

discussed in bBird team mtg.  plussing for adt

Comment 28

[Jaime Rodriguez, Jr.]

Marking as Mozilla1.0.2+ per Comment #26 From chris hofmann.

karnaze: pls land this asap. Thanks!

Comment 29

[karnaze (gone)]

fixed1.0.2

Comment 30

[Michael Dunn]

Internal reference:
http://bugscape.mcom.com/show_bug.cgi?id=20525

amar please verify as fixed against branch

Comment 31

[Katsuhiko Momoi]

It helped me to clean the cache for each test instance to see
the effect of this fix correctly.

Comment 32

[Amarendra Hanumanula]

Verified on Branch build: 2002-10-23-08-1.0 on WIN2K and Linux7.1