Closed Bug 121142 Opened 23 years ago Closed 16 years ago

Multiple anonymous table-rows erroneously created when delayed

Categories

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

Product:
Core
Component:
Layout: Tables
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: johann.petrak, Assigned: bzbarsky)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: css2, testcase)

Attachments

(4 files, 1 obsolete file)

X screen dump of incorrectly rendered page, created with xwd
86.89 KB, image/png
Details
Self-contained testcase
1.47 KB, text/html
Details
page is not rendered properly
188.99 KB, image/jpeg
Details
testcase2
258 bytes, text/html
Details
Using build 2002011708/linux: when i go to http://www.mozillazine.org/ and click on the "Build Comments" link in the top bar, the next page sometimes gets rendered so that it is shown in a narrow column to the left of the browser window. This seems to happen randomly, since sometimes, the page occupies all of the window. I tried going back and forth between the main page at http://www.mozillazine.org/ and http://www.mozillazine.org/build_comments/ by repeatedly clicking the link and the back button. The result was that out of 20 times, the page was shown wrong 5 times.
Confirming on 2002011503 Win2k. Over to Layout.
Assignee: asa → attinasi
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: doronr → petersen
The big white space actually is in the browser's default background color, not in the page's bg color.
using moz0.9.7 on winme. on 0.9.7: 1) loading http://www.mozillazine.org or http://www.mozillazine.org/build_comments/ (from a link or bookmark) after emptying cache and history results in a proper layout on load completion. 2) loading either page from a link or bookmark after having viewed the other page first *always* results in the layout error described above, but only on load *completion*. during the loading process, the page layout is correct. 3) returning to either page from another page by using the back or forward buttons results in proper layout, regardless of the layout on previous views. evidently something between 0.9.7 (which is labelled 2001122106, btw) and the reporter's build caused this to go from constant to intermittent.
I'm also seeing this on Windows XP Home Edition on 2002012103. I havn't tested this or anything, but the width of the thin column that the page appears in, looks like it's the same width as the right hand side navigation menu is meant to be.
OS: Linux → All
I can reproduce this issue under the OS X Jan 18th build (2002-01-18-08) with a similar procedure. 1) Deleted memory and disk cache in Preferences 2) Go to this bug report 3) Click on url link to load http://www.mozillazine.org/build_comments/ 4) After page loads, press the back toolbar arrow to return to report 5) Click on url link once again in report. 6) The mozillazine page is rendered as one left-aligned column. Reloading page will layout document correctly.
*** Bug 121293 has been marked as a duplicate of this bug. ***
Confirmed on 2002012308 on Linux
Confirmed. (Build ID: 2002 01 23 04/Win98). on http://www.mozillazine.org/build_comments/ when i get a wrong display, using the link "build comments" to refresh the page keep the same layout, using View/Reload display the right one.
Sorry, clicked Commit a bit too fast... Anyway the site www.tomshardware.com also displays the same sort of problems.
I'm seeing this with Netscape 6.2.1 on Mac OS 9.2.2 (and had only been seeing it thus recently), so it's not just a recent problem.
Yhis has gotten worse in build id: 2002012403 OS is win 98 I can NOT get http://www.mozillazine.org/build_comments/ to display properly no matter how many times I reload or click the link. It stays in a narrow column on the left. Some of the other mozillazine pages had the problem on first load, but cleared with reloads
*** Bug 121803 has been marked as a duplicate of this bug. ***
*** Bug 121817 has been marked as a duplicate of this bug. ***
Attached image layout of tomshardware.com (obsolete) —
My experience is: with build post 097 i experience the bug, but reloading page will layout document correctly. With the most recent build, 2002012403, build_coments page never layout correctly. But I have tried now, and after reload all apage on mozillazine layout correctly, build_comment included. It's a bit curious... Tom's Hardware is layout differentrly... the page start with many lines of nothing on top. I will attacch screenshot.
now using win32 full installer build 200212403. behavior is essentially the same as 0.9.7 (see my comment above). a few extra notes: 1) if cache is emptied and a link to either the mozzine home page or the build comments is clicked, both pages are rendered correctly. 2) reload fixes the mozzine home page, but not the build comments page. 3) using the back and forward buttons renders both pages correctly *unless* the cache is emptied before going back or forward to the other page. since it then has to be loaded anew, the formatting is again messed up. 4) clearing history entries appears to have some relevance, but i am yet to figure it out.
seems like the display: table-cell; on class="content" and class="sidebar" is not triggering the creation of a anonymous table-row object like it says in CSS2. Seems to happen almost all the time now for me with build 2002012304
ok, just realized something: <div class="fullPage"> <---- display: table; in stylesheet <---- I suspect we are missing anonymous table-row and/or table-row-group object here. <div class="content"> <---- display: table-cell; in stylesheet
This gets weirder, in DOM inspector I find that the fullPage rule in the stylesheet doesn't get applied, and the anonymous table rule from html.css gets applied instead. BTW, this is a great testcase to freeze DOM Inspector.
Daniele: the tomshardware site bug is a different bug. Probably bug 120087
Created a test: http://www.shop-engine.nl/moztest/divs.php Little php-script with a sleep between the two cells to simulate slow link. Upper row is with table-row div, other row is missing it. Most of te time (when using a long sleep) the bottom row gets painted wrong. Upper row is ok all of the time. See http://www.shop-engine.nl/moztest/divs.txt for the php source.
Blocks: advocacybugs
*** Bug 122192 has been marked as a duplicate of this bug. ***
Per #23 Platform should be changed to ALL
it doesn't really matter if platform=ALL (OS is inclunding MAC)
Hardware: PC → All
This needs a more descriptive Summary now.
Target Milestone: --- → mozilla1.0.1
Target milestone 1.01 now -- so, should Jason ( and I, to the extent that I care ) consider doing away with CSS layout of Mozillazine for Mozilla users? Because this bug makes parts of MZ barely usable. Sometimes reloading MZ pages multiple times produces no improvement in the layout. Sometimes reloading once does. I was assuming it would be met with a quick fix. But 3 milestones away seems like we should consider alternative solutions, because Mozilla's loading of CSS files does not seem ready for primetime.
Furthermore it's a regression. It should be fixed ASAP.
Chris, the workaround is to avoid using "display: table-cell" until this bug is fixed. If you use HTML tables instead, you won't see the problem.
Not to be argumentative, but that's exactly what I said. Mozillazine's layout would have to change to accomodate this bug (apparently a recent regression).
I was about to test this bug further but I'm no longer having the issue with www.mozillazine.org with build 2002012803 win32 trunk.
The correct testcase is that one in comment 22. The layout is dependent on the network connection speed and so on. I'm not sure it's regression. The mozillazine site was completely rewritten recently and the bug was visible there from the rewrite of the site. But the bug could be for very long time in Mozilla. The simple solution for mozillazine is to add a table-row div which would encapsulate the table-cell divs.
URL: http://www.mozillazine.org/build_comm... → http://www.shop-engine.nl/moztest/div...
Taking a shot at a revised Summary.
Summary: intermittent layout bug → Sometimes an anonymous table-row isn't inserted when necessary
Can we up the target milestone to 1.0 until we are sure we can't fix this before 1.0?
Reassigning to HTMLTables on advice of timeless and bz.
Component: Layout → HTMLTables
Reassigning to default owner.
Assignee: attinasi → karnaze
QA Contact: petersen → amar
Testing for regression . . . still see this problem as far back as 0.9.2 (Fizzilla).
Tested all the way back to M3 and the testcase still fails. Removing regression keyword. (I tested 0.8.1, 0.6, M13, and M8 in addition to M3. All I can say is, my, oh my, how far we've come.)
Keywords: regression
Wonderful I can't believe someone would even try to go that far back in history! :-))) Sorry for spam...
Priority: -- → P2
Adding css2 keyword as this is a fault in the implementation for table display properties.
Keywords: css2
Blocks: 120946
*** Bug 125498 has been marked as a duplicate of this bug. ***
*** Bug 126032 has been marked as a duplicate of this bug. ***
is bug 121913 a dup? this really should be easier to find. how about a link from mozillazine?
*** Bug 121913 has been marked as a duplicate of this bug. ***
*** Bug 126517 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.9 → mozilla1.0
*** Bug 127811 has been marked as a duplicate of this bug. ***
[ I haven't read all comments before ... sorry if it is spam ! ] As for me, the "sometimes" in the summary would better be replaced by "always" ... at least with http://www.mozillazine.org/build_comments/ . Running mozilla 2002022208 on Linux 2.4.18 .
Another page showing the bug ... http://www.zdnet.com/downloads/stories/info/0,,68234,.html I've tried to reload that page about 5 times, and it has always been rendered as a one left-aligned column. Really think this bug should be fixed : users will think mozilla is not ready for real world use if they see that.
Comment on attachment 66450 [details] layout of tomshardware.com Thibault G. : apologizing for spam is still spam, so please just read the comments. And as for the zdnet link it is not this bug, I'm not sure what is causing that. But it has nothing to do with this, maybe something with the tomshardware one (which also happens to have no relation to this)
Attachment #66450 - Attachment is obsolete: true
zdnet bug is bug #122200 which has a patch but no agreement if it's the right thing to do.
[ sorry for last comment : it was spam ... :(( ] While 2002022208 was displaying http://www.mozillazine.org/build_comments/ wrong *every* time on my system, 2002022608 displays it correctly *sometimes* after having reload the page. But there's something new : the page is no longer displayed as a narrow column, but a wide and normal one *every* time. The only remaining bug is the bar on the right which sometimes get displayed below the wide column, instead of next to it.
*** Bug 129993 has been marked as a duplicate of this bug. ***
*** Bug 131394 has been marked as a duplicate of this bug. ***
*** Bug 133907 has been marked as a duplicate of this bug. ***
*** Bug 126876 has been marked as a duplicate of this bug. ***
Depends on: 148810
Keywords: mozilla1.0 → mozilla1.2
Has anyone bothered to create a minimal testcase for this? What makes us think the anonymous row is not getting constructed?
The URL in comment 22 demonstrates the problem well. It would be nice to see that testcase with the CSS embedded and the timing effects applied via embedded JavaScript rather than server-side PHP.
The URL in comment 22 does not seem to show any problem at all... no matter what timeout I select I get the following rendering: left right left right Which is correct...
Boris, both tables draw one cell, pause, then draw the other cell. In table one, there is an explicit table-row, so both table-cells are drawn in that row. In table two, there is no explicit table-row, so Mozilla should generate an anonymous one. left and right should be in the same row, but they are not. Is Mozilla generating table-rows around both table-cells in this case?
> left and right should be in the same row Ah, good point. So they should. I hadn't realized the CSS2 spec actually specified that. ;) > Is Mozilla generating table-rows around both table-cells Yep. That's what it's doing. Mind if I resummarize to reflect the real problem?
Here's a self-contained testcase, containing the CSS and timing.
Comment on attachment 94811 [details] Self-contained testcase Odd, it doesn't seem to layout progressively as XML, but does as HTML.
Attachment #94811 - Attachment mime type: application/xml → text/html
Revising summary and raising severity.
Severity: normal → major
Summary: Sometimes an anonymous table-row isn't inserted when necessary → Multiple anonymous table-rows erroneously created when delayed
Keywords: testcase
Still evident using FizzillaCFM/2002103011.
Removing mozilla1.2 keyword, that's long since shipped (as has 1.3).
Keywords: mozilla1.2
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: mozilla1.0.1 → ---
Target Milestone: --- → Future
is this visualization problem related to this bug? I have not experienced this bug for a long time, it is returned today and I remember that this bug should be the problem. mozilla 1.4b, winXP.
Blocks: 208305
At least the gamespy site renders correctly now with firefox 0.8! Can this bug be marked fixed or did the gamespy site expose another bug?
(In reply to comment #69) > At least the gamespy site renders correctly now with firefox 0.8! > > Can this bug be marked fixed or did the gamespy site expose another bug? No - the testcase still shows the bug.
*** Bug 234021 has been marked as a duplicate of this bug. ***
*** Bug 326546 has been marked as a duplicate of this bug. ***
On other Mac browsers showing attachment 94811 [details]: Safari 2.0.4 passes, Opera 9.10 fails.
Attached file testcase2 —
Blocks: 432288
Fixed by checkin for bug 148810. Added tests.
Assignee: layout.tables → bzbarsky
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: