auto-width table layout wrong when given size of all columns

VERIFIED FIXED in M18

Status

()

Core
Layout: Tables
P1
normal
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Derwood, Assigned: karnaze (gone))

Tracking

({testcase})

Trunk
x86
Windows NT
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+], URL)

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
Using 11/15/99 win32 build, the abouve URL laysout text too far to the right so
that text is obscured.

Comment 1

18 years ago
This seems like a painting issue, not tables. If the screen is wide, then things
are fine. If i make the window narrow enough to make a horizontal scrollbar and
then scroll all the way to the right, the part that was previously obscured has
a black background color. If i click on the vertical scrollbar and drag it
slowly, the background is repainted with the proper background color or
sometimes with stuff that looks like unitialized memory. Clicking on the up/down
arrows of the scrollbar also paints correctly. Clicking above or below the
grippy thing to scroll up and down a page at a time paints the stripe black
again.
(Assignee)

Updated

18 years ago
Assignee: karnaze → kmcclusk
(Assignee)

Comment 2

18 years ago
Reassigning to Kevin based on last comments.

Comment 3

18 years ago
I forgot to mention that I'm using the intel linux m11 build so this problem is
xp.
(Reporter)

Comment 4

18 years ago
Video resolution is set to 1024x768 w/Moz maximized to full screen with the
sidebar disabled. Ook! Ook!

Updated

18 years ago
Assignee: kmcclusk → beard
Patrick, sounds like another scrolling view update issue.

Updated

18 years ago
Assignee: beard → karnaze

Comment 6

18 years ago
The problem I see with the sfgate page is that if you resize the window to be
very wide,  the text in the right column bleeds into the black background. I
don't see this when scrolling in a narrow window on the Mac. This looks more like
a table problem to me. I doubt it's got anything to do with scrolling because it
happens when there's no horizontal scroll bar.

Comment 7

18 years ago
Created attachment 3418 [details]
testcase; at least part of the problem for sfgate.com

Comment 8

18 years ago
I think the attachment (as over-simplified as it is) characterizes the core
problem for sfgate.com -- another variation on colspan-width type of problems.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M14
(Assignee)

Comment 9

18 years ago
Adding keywords layout colspan.
(Reporter)

Comment 10

18 years ago
The 2000011210 Win32 build lays this page out correctly! =)
... but 2000012208 (Win32) does not. In fact, the amount of bled text changes 
from time to time. However, the test case seems to lay out fine in the above 
build... I might come back later and try and do another TC.

Gerv
(Assignee)

Comment 12

18 years ago
I'm not seeing the problem in the testcase or the url.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 13

18 years ago
Huh?  It's still broken on the 2000021307 win32 build.

Comapre the site with 4.61 or 4.7 -- the second column does not line up properly 
and the back text which would be on the blue is over on the black border and is 
unreadable.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 14

18 years ago
The url looks very good to me compared to Nav4.6. I have a debug build pulled 
around 3:15 pm pst. If you are running an optimized build that could explain the 
difference. Otherwise, I'm not sure how to explain the differences.
(Assignee)

Comment 15

18 years ago
Moving to M15.
Target Milestone: M14 → M15

Comment 16

18 years ago
www.sfgate.com looks pretty much identical to 2000-02-15-09 win95 (I see no
overlapping text, or any other glaring problems). 

However, my attachment 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3418 still 
demonstrates a small problem with table width calculation. The two tables
in the attachment should be the same, fixed width (~490px). However, mozilla
displays the first table as full width of the screen.
(Reporter)

Comment 17

18 years ago
Created attachment 5326 [details]
incorrect layout
(Reporter)

Comment 18

18 years ago
Created attachment 5328 [details]
correct layout
(Reporter)

Comment 19

18 years ago
attachments uploaded showing current horkage, note Im running on NT 4.0sp6a
(Reporter)

Comment 20

18 years ago
Additional note, I have an ATI graphics card whose driver may be causing the 
problem as you can see in the attachments (the SFGate logo is displayed 
incorrectly).  I've reloaded NT and I'm trying to downrev the drivers to be 
sure.

The afected images displat fine if I scroll them off then on the page again.  My 
be a non-related window update problem.
(Assignee)

Updated

18 years ago
Status: REOPENED → ASSIGNED
(Reporter)

Comment 21

18 years ago
2000030208 win32 build seems to have nailed it, but this has happened before.
(Reporter)

Comment 22

18 years ago
*sigh*, 2000030504 win32 build croaks on this again.  Wnder why it's 
intermittant...
Still broke, both in testcase and on page, in 20000324 tip Win95.

Gerv
(Assignee)

Comment 24

18 years ago
mass move to m16
Target Milestone: M15 → M16
(Assignee)

Comment 25

18 years ago
Moving to M17.
Target Milestone: M16 → M17
(Reporter)

Comment 26

18 years ago
2000051713 win32 build displays correctly.

Updated

18 years ago
Keywords: testcase

Comment 27

17 years ago
(ignore the original URL, focus on the test case 12/11/99 23:03)
A table with auto width, and all column widths specified, should have a fixed 
width.  It does not, it is acting as if it were completely auto width.  This is 
a very basic HTML 3.2/CSS1 error
Keywords: 4xp, nsbeta3
Summary: Page layout differs from Communicator 4.7 → auto-width table layout wrong when given size of all columns

Comment 28

17 years ago
Approving for beta3: hoping too that this is an easy fix...
Whiteboard: [nsbeta3+]
Target Milestone: M17 → M18
(Reporter)

Comment 29

17 years ago
what service.  There's still a bug in Confusicator 4.73 that I reported in 4.0.  
Still open.

Updated

17 years ago
Priority: P3 → P1

Comment 30

17 years ago
PDT agrees P1
(Assignee)

Comment 31

17 years ago
Fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED

Comment 32

17 years ago
Using 9/8 build, verified bug fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.