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
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.
Created attachment 81577 [details] out-of-line script.
Created attachment 81578 [details] 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.
Created attachment 81602 [details] 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?
-> HTML tables. I'll let the pros handle this. :-)
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.
Taking the bug. I'll be attaching a patch, since the revised patch in bug 120107 does not fix this.
Created attachment 82606 [details] [diff] [review] patch to fix the bug (ignore the previous one)
Created attachment 82630 [details] [diff] [review] revised patch
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 on attachment 82630 [details] [diff] [review] revised patch sr=waterson
Nominating for nsbeta1 and topembed. Needed for a bank customer in Japan.
Can we check this into 1.0.2 branch?
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.
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!
Per adt, please verify on trunk for adt approval.
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.
Per amar's comment #24, this bug is now verified as dixed.
Comment on attachment 82630 [details] [diff] [review] revised patch a=chofmann for 1.0.2
discussed in bBird team mtg. plussing for adt
Marking as Mozilla1.0.2+ per Comment #26 From chris hofmann. karnaze: pls land this asap. Thanks!
Internal reference: http://bugscape.mcom.com/show_bug.cgi?id=20525 amar please verify as fixed against branch
It helped me to clean the cache for each test instance to see the effect of this fix correctly.
Verified on Branch build: 2002-10-23-08-1.0 on WIN2K and Linux7.1