Open Bug 453967 Opened 16 years ago Updated 2 years ago

html TD width statement continues to next TD or TR

Categories

(Core :: Layout: Tables, defect)

defect

Tracking

()

People

(Reporter: dickhb, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Firefox problem 9/4/08           from:   dickhb@netzero.net
The example below illustrates the problem that the latest version of Firefox has displaying html code.
The width=6 description of the TD definition is supposed to apply only to the TD statement in which
it is incorporated.
In the example below, the width=6 description is carried on into all subsequent TR statements within the TABLE.
This does not happen in Mozilla or previous versions of Firefox.


<TABLE cellSpacing=2 cellPadding=0 width=299 border=0>
                    <TBODY>
               <TR>
                      <TD width=6></TD>
                      <TD></TD>
                      <TD></TD></TR>
              <TR>
                      <TD><B>Prime Casting Reels</B></TD></TR>
            <TR>
                     <TD>&#8226;Super Light &amp; Strong Magnesium Frame</TD></TR>
And so forth for the remaining TR statements in the TABLE unless a new width is defined.


Reproducible: Always

Steps to Reproduce:
1.Just run the example in details
2.
3.
Actual Results:  
Subsequent TR TD in table display the previous width

Expected Results:  
TD width statement should pertain only in that TD
As previous Firefox and Mozilla versions do.

I have to examine large website and remove the offending problem with workaround until bug is fixed.
Caused by Bug 413286 ?
Blocks: 413286
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Version: unspecified → Trunk
(In reply to comment #0)
> The example below illustrates the problem that the latest version of Firefox
> has displaying html code.

Dick: Can you attach an HTML file testcase that demonstrates the problem, rather than posting HTML in a comment?
Attached file testcase 1
Nevermind -- here's a testcase based on comment 0.

Firefox 2.0.0.16 and Midori (WebKit recent-ish trunk) both expand the first column. 

Firefox 3.0.1 and mozilla-central trunk both clip the first column at the first specified width.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #3)
> Firefox 3.0.1 and mozilla-central trunk both clip the first column at the first
> specified width.

oops -- I meant "at the first _cell's_ specified width"
(In reply to comment #1)
> Caused by Bug 413286 ?

Nope -- I can reproduce the bug in older builds.  Looks like a reflow-branch regression, actually, as it regressed between these two builds:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061207 Minefield/3.0a1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1
Blocks: reflow-refactor
No longer blocks: 413286
(In reply to comment #3)
> Firefox 2.0.0.16 and Midori (WebKit recent-ish trunk) both expand the first
> column. 
... as do Opera and IE8 beta.

 So, FF3 is the only browser to clamp that first column, AFAIK.
What happens if you swap the order of the rows in the table?  (Especially in IE7.)
This testcase has the rows reversed vs. the previous one.

The row reversal doesn't seem to affect behavior in WebKit, Opera, Firefox 2, or Firefox 3.

However, IE8b does indeed change its behavior with the rows reversed -- it switches to match FF3, with a skinny first column.  (dbaron mentioned IE7, but I'm not sure I can test IE7 with IE8b installed.)
Daniel do you still see the reversed order problem, I do not.
To clarify -- there was no "reversed order problem" here.  The reversed-order testcase was just to demonstrate that IE's behavior depends on the order of the rows, whereas Gecko's & Webkit's behavior does not.

AFAICT, no behavior has changed on this bug - the situation is the same as in Comment 3.

 - Gecko (Nightly) still renders the first column skinny (both testcases)
 - Webkit (Chromium) still renders the first column wide (both testcases)
 - Haven't tested IE (not booted into windows right now), but I assume they still behave as in Comment 8.

Firefox ver: Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20111225 Firefox/12.0a1
Chromium ver: 15.0.874.120 (Developer Build 108895 Linux) Ubuntu 12.04

Issue still reproducible on the latest Nightly 97.0a1 on both Mac OS X 11.6 and Windows 10 x64 - the first column is still skinny.

Severity: major → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: