Closed Bug 109066 Opened 24 years ago Closed 24 years ago

Tables laid out improperly; Inconsistence between page reloads

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: aleksander.adamowski, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: [bae:20011108])

Attachments

(4 files)

Zipped testcase (html file + gif image)
910 bytes, application/x-zip-compressed
Details
Windows 2000 screenshot
8.76 KB, image/png
Details
Linux screenshot
6.24 KB, image/png
Details
Simple testcase
771 bytes, application/x-zip-compressed
Details
This regressed between trunk builds 2001102309 and 2001102503 Testcase HTML code taken from http://www.linuxgames.com and reduced to a simple testcase. I can reproduce this on Windows 2000 and Linux. To reproduce: 1. In Mozilla, go to http://office.altkom.com.pl/mozilla/browser/2001_11_08/ or unzip and open attached testcase. 2. Reload the page. Observed behaviour: After the reload, tables on the page are laid out improperly - they overlap. Sometimes, after several reloads, tables become laid out properly, but after next reload they overlap again (I can always observe this when opening the page locally from HDD). This is a serious issue - those tables shouldn't overlap, and most of all, Mozilla should display pages coherently regardless of number of times they are reloaded and displayed. BTW, This document isn't completely valid HTML because I omitted doctype, encoding, <HEAD> element and <TR> elements to keep the testcase short. Adding them has no effect on the problem.
I also noticed that opening a new tab (ctrl-t) corrects that layout...
-> Tables
Assignee: attinasi → karnaze
Component: Layout → HTMLTables
QA Contact: petersen → amar
Using the trunk build from today (2001110803) on win2000, I cannot repro this bug. If I view the test case on win98, I do see a pixel or two of space between the tables, which I do not see on win2000. Reporter, can you install a newer build and see if you can repro. If you can, please reopen. A screen grab would be outstanding as well.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Whiteboard: [bae:20011108]
It's still broken. W2K build 2001110803 Linux build 2001110821 Screenshots coming.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Attached image Windows 2000 screenshot —
Attached image Linux screenshot —
I have pinpointed the builds between which this regression occured: It's between 2001102403 and 2001102503.
I'm seeing overlap of the tables on a 11/8 debug win2k build. I looked at bonsai for a checkin that might have caused this but didn't locate one. It looks like a floater problem. -->attinasi,waterson
Assignee: karnaze → attinasi
Status: REOPENED → NEW
Keywords: testcase
I looked at checkins around the times mentioned in comment 8. It could be bug 106336, but that one deals with cellspacing and cellpadding, neither of which affect the testcase on this bug. But there was a big checkin by dbaron that affected layout: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=dbaron%25fas.harvard.edu&whotype=match&sortby=Change+Size&hours=2&date=explicit&mindate=10%2F24%2F2001+3%3A00&maxdate=10%2F25%2F2001+3%3A00&cvsroot=%2Fcvsroot This checkin affected the following bugs: (according to CVS comments) bug 86947 (main bug) bug 61962 bug 48138 (summary says that this bug has to do with IMG....) bug 50142 I also played with the testcase. The first attachment is the simplest testcase I could come up with. (zipped up for d/l). To see the bug: 0) border=1 is nonessential for this bug, it just makes things easier to see 1) The first table must be in CENTER tags. 2) The first table must have an align=left in the TABLE tag. 3) There must be an IMG in the second table. 4) Said IMG must have neither the width nor the height specified. Interesting (side?) note about the IMG size attributes in the testcase: If you only specify one or the other of width and height AND the image must be scaled to meet the given size, the NON-SPECIFIED attribute will ALSO BE SCALED by the same factor as the specified attribute!!! Weird.
Attached file Simple testcase —
Looks like this bug is a dup of the (now fixed) bug 106658.
Severity: major → normal
Target Milestone: --- → mozilla1.0.1
I can't repro this anymore with build 2001113003 on w98. fixed?
Yes, it seems fixed on Linux and Windows.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: