<table width=n%> lays out incorrectly.

VERIFIED FIXED in M4

Status

()

P2
normal
VERIFIED FIXED
20 years ago
20 years ago

People

(Reporter: phillip, Assigned: karnaze)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

20 years ago
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...

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → WORKSFORME

Comment 1

20 years ago
I don't see this problem on NT or Win98, debug or optimized build.
(Reporter)

Updated

20 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 2

20 years ago
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.

Updated

20 years ago
Resolution: WORKSFORME → ---

Comment 3

20 years ago
this only happens in the non-debug build.  Any subsequent resize fixes the
display.
(Reporter)

Updated

20 years ago
Summary: table #2 on test4 renders incorrectly → width=n% lays out incorrectly.
(Reporter)

Comment 4

20 years ago
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.
(Reporter)

Updated

20 years ago
Summary: width=n% lays out incorrectly. → <table width=n%> lays out incorrectly.
(Reporter)

Comment 5

20 years ago
updated summary and added new url for test case.

Comment 6

20 years ago
Believe that Bug #1699 is a dup and will make it so.  URL in that bug was:
http://www.mozilla.org/stevecase.html

Comment 7

20 years ago
*** 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.

Comment 9

20 years ago
*** Bug 2065 has been marked as a duplicate of this bug. ***

Updated

20 years ago
Assignee: buster → karnaze
Status: REOPENED → NEW
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 10

20 years ago
Setting all current Open/Normal to M4.
(Reporter)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: --- → FIXED
(Reporter)

Updated

20 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 11

20 years ago
this looks has been fixed, so i'm resolving...
(Reporter)

Comment 12

20 years ago
...and verifying fixed
(Reporter)

Updated

20 years ago
Status: VERIFIED → REOPENED
(Reporter)

Comment 13

20 years ago
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?)
(Reporter)

Updated

20 years ago
Resolution: FIXED → ---
(Reporter)

Comment 14

20 years ago
clearing resolution
(Reporter)

Comment 15

20 years ago
clearing resolution

Comment 16

20 years ago
This only occurs in optimized builds.  There are several bugs like this.

Updated

20 years ago
Status: REOPENED → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: --- → FIXED

Updated

20 years ago
QA Contact: 3849

Comment 17

20 years ago
mik@rheintal.ch -- did you check in a fix? If so, when did you check it in? Or
are you QA'ing this one?

Comment 18

20 years ago
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.

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 19

20 years ago
using 3/4 & 3/5 builds. tested this on win95, win98, winNT and mac -- renders
correctly. marking bug verified.

Comment 20

20 years ago
using 3/4 & 3/5 builds. tested this on win95, win98, winNT and mac -- renders
correctly. marking bug verified.

Comment 21

20 years ago
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.