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)
Core
Layout: Tables
Tracking
()
NEW
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>•Super Light & 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.
Comment 1•16 years ago
|
||
Caused by Bug 413286 ?
Blocks: 413286
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Version: unspecified → Trunk
Comment 2•16 years ago
|
||
(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?
Comment 3•16 years ago
|
||
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.
Updated•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•16 years ago
|
OS: Windows XP → All
Hardware: PC → All
Comment 4•16 years ago
|
||
(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"
Comment 5•16 years ago
|
||
(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
Comment 6•16 years ago
|
||
(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.
Updated•16 years ago
|
Keywords: regression,
testcase
What happens if you swap the order of the rows in the table? (Especially in IE7.)
Comment 8•16 years ago
|
||
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.)
Comment 10•12 years ago
|
||
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
Comment 11•2 years ago
|
||
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.
Description
•