Closed Bug 1474 Opened 26 years ago Closed 26 years ago

<table width=n%> lays out incorrectly.

Categories

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

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: phillip, Assigned: karnaze)

References

(
URL
)

Details

xpviewer.exe on NT4.0 Nov 20, 1998 File|Samples|Demo#4 (resource:/res/samples/test4.html) the problem: the second table's right outside border often is drawn to the LEFT of the actual edge of the table. That is, the rightmost column of the table is drawn too far to the right of the table outline... process for duplication: 1. go to the Demo #4 resource page. 2. if you're lucky, the second table has already been drawn incorrectly 3. if not, resize the window 4. click in the location URL as if you were going to change the text 5. hit return, then go to step 2. The other 4 tables seem to draw fine...
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
I don't see this problem on NT or Win98, debug or optimized build.
Status: RESOLVED → REOPENED
I still exhibit the problem on both windows 95 and windows NT 4.0. the table will redraw itself incorrectly only after you put the cursor in the Location field and hit the enter key.
Resolution: WORKSFORME → ---
this only happens in the non-debug build. Any subsequent resize fixes the display.
Summary: table #2 on test4 renders incorrectly → width=n% lays out incorrectly.
ok, i think i found the problem. i made a few tables and i discovered that when you create a table with the width as a percent, this problem occurs. These types of tables will always produce this bug. <TABLE WIDTH=70% BORDER> ....... </TABLE> <TABLE WIDTH=70% BORDER=3> ....... </TABLE> not only that, try this test, also because of the % in the width element: <html><body> <TABLE WIDTH="80%" BORDER=1> <TR><td>one</td><td>two</td><td>three</td><td>four!</td></TR> </TABLE> </body></html> a table will be drawn with 2 cells. hit the reload button to see these 2 cells. now resize the window and the screen is correctly redrawn, with 4 cells.
URL: resource:/res/samples/test4.html → http://juicetiger/bug1474.html
Summary: width=n% lays out incorrectly. → <table width=n%> lays out incorrectly.
updated summary and added new url for test case.
Believe that Bug #1699 is a dup and will make it so. URL in that bug was: http://www.mozilla.org/stevecase.html
*** Bug 1699 has been marked as a duplicate of this bug. ***
Two things I believe are related: #1: As of 1998-12-19, the Steve Case page is still broken. #2: the 100% width nested page on test6, resource:/res/samples/test6.html, does not render the last two columns until a resize. Once resized, it appears to be fine.
*** Bug 2065 has been marked as a duplicate of this bug. ***
Assignee: buster → karnaze
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Setting all current Open/Normal to M4.
URL: http://juicetiger/bug1474.html → http://wetnap/seamonkey/bugs/bug1474....
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
this looks has been fixed, so i'm resolving...
...and verifying fixed
Status: VERIFIED → REOPENED
i'm reopening this bug. it has regressed on all platforms. builds tested: redhat 5.2 build 99021012 macos 8.51 build 99020914 nt4.0 sp4 build 99020915 expected output: a table that looks like this: ===================================================== | one | two | three | four | ===================================================== actual output (varies slightly by platform): =================---- | one | t|wo =================---- one possible way to fix this would be to reflow the document (or just the table) right before it is drawn, but i don't think that would be doing the right thing. shouldn't the table know it's width before it starts drawing? or if it doesn't, should it resize itself and then ask the view system to redraw it? (am i confused?)
Resolution: FIXED → ---
clearing resolution
clearing resolution
This only occurs in optimized builds. There are several bugs like this.
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
QA Contact: 3849
mik@rheintal.ch -- did you check in a fix? If so, when did you check it in? Or are you QA'ing this one?
I checked in a fix for this and other bugs that only showed up on optimized builds last Sunday. I haven't gone through the bug list to see which reports are fixed as a result of my checkin. I'm sure this one was, there may be others.
Status: RESOLVED → VERIFIED
using 3/4 & 3/5 builds. tested this on win95, win98, winNT and mac -- renders correctly. marking bug verified.
using 3/4 & 3/5 builds. tested this on win95, win98, winNT and mac -- renders correctly. marking bug verified.
using 3/4 & 3/5 builds. tested this on win95, win98, winNT and mac -- renders correctly. marking bug verified.
You need to log in before you can comment on or make changes to this bug.