Closed Bug 207279 Opened 22 years ago Closed 3 years ago

<td nowrap> sizes to just text when floating image present

Categories

(Core :: Layout: Floats, defect, P3)

Product:
Core
Component:
Layout: Floats
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: dpbackes, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(4 files)

Testcase #1
1.85 KB, text/html
Details
Testcase #2
730 bytes, text/html
Details
why do these two testcases display differently?
441 bytes, text/html; charset=iso-8859-1
Details
strict testcase
733 bytes, text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030526 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030526 On the page listed above, you will notice that the text "WX Stickers" overlaps the image in what is supposed to be the "level link" tab, and so on for every tab that has an image in it. I think that this stems from teh NOWRAP option in the TD tag and is related to the images being in the columns because the columns w/o images display their text fine. Reproducible: Always Steps to Reproduce: 1. Go to http://www.wx.com/link/ 2. Open Eyes 3. Look at table Actual Results: <td>'s do not size accordingly to text and image Expected Results: the image and text should both fit within the width of the <td>
The image is floating (align="left" is equivalent to CSS 'float: left'), so this is a somewhat complicated case.
Attached file Testcase #1 —
Severity: normal → minor
Keywords: testcase
OS: Windows XP → All
Summary: <td nowrap> sizes to just text when image present → <td nowrap> sizes to just text when floating image present
Attached file Testcase #2 —
Even smaller testcase.
could this be a dup of bug 144595 ?
No, since it doesn't have a testcase. It's possible that that bug could be a duplicate of this one, though.
*** Bug 205353 has been marked as a duplicate of this bug. ***
With a minor severity, and an unconfirmed status, is there any chance a fix for this bug will make it into 1.4? See notes in 205353 for more info. BTW, this used to work in 1.3.
Severity: minor → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Do you know when (what day) it regressed? Knowing that might help.
this regressed between linux trunk builds 2003022205 and 2003022305, implicating the secondary checkin from bug 119100 (to fix build warnings): http://bonsai.mozilla.org/cvsquery.cgi?who=bmlk%25gmx.de&whotype=match&sortby=Date&date=explicit&mindate=03%2F21%2F2003+11%3A33%3A00&maxdate=03%2F22%2F2003+04%3A25%3A00 ==> Bernd
Assignee: table → bernd_mozilla
The dates don't correspond to the checkin range (February vs. March). Which is wrong?
(I think it's much more likely that the dates are right and that this is the result of bug 186593. In fact, I think I assumed that the first time I looked at the bug, but then forgot...)
> The dates don't correspond to the checkin range (February vs. March). Which is > wrong? March was wrong, sorry. backing out bug 186593 fixed this bug.
this is a float bug
Assignee: bernd_mozilla → float
Component: Layout: Tables → Layout: Floats
QA Contact: madhur → ian
Attached file strict testcase —
attachment 124691 [details] displays differently because in quirks mode the first testcase does not honour the nowrap attribute when a width is specified for the cell ( the width wins over the nowrap). The second testcase exhibits the bug: scroll 00BB03D4 r=1 a=9180,4470 c=9180,4470 cnt=853 canvas 00BB013C r=1 a=9180,UC c=9180,4470 cnt=854 area 0264AB0C r=1 a=9180,UC c=9180,UC cnt=855 block 0264AD20 r=1 a=9180,UC c=8940,UC cnt=856 text 0264AF40 r=0 a=8940,UC c=UC,UC cnt=857 text 0264AF40 d=0,0 tblO 0264B0A8 r=0 a=8940,UC c=0,0 cnt=858 tbl 0264B218 r=0 a=8940,UC c=2970,UC cnt=859 rowG 0264B3F0 r=0 a=UC,UC c=UC,UC cnt=860 row 0264B598 r=0 a=UC,UC c=UC,UC cnt=861 cell 0264CA8C r=0 a=UC,UC c=UC,UC cnt=862 block 0264CB30 r=0 a=UC,UC c=UC,UC cnt=863 place 0264CF60 r=0 a=UC,UC c=UC,UC cnt=864 place 0264CF60 d=0,0 me=0 img 0264CEE0 r=0 a=UC,UC c=450,450 cnt=865 img 0264CEE0 d=450,450 me=450 text 0264CFC4 r=0 a=UC,450 c=UC,UC cnt=866 text 0264CFC4 d=330,285 me=330 block 0264CB30 d=780,450 me=450 <<<<<< this should be 450 +330 cell 0264CA8C d=840,510 me=510 cell 0264D0C8 r=0 a=UC,UC c=2700,UC cnt=867 block 0264D16C r=0 a=UC,UC c=UC,UC cnt=868 text 0264D218 r=0 a=UC,UC c=UC,UC cnt=869 text 0264D218 d=60,285 me=60 block 0264D16C d=60,300 me=60 cell 0264D0C8 d=120,360 me=120 row 0264B598 d=UC,510 rowG 0264B3F0 d=UC,510 colG 0264D368 r=0 a=UC,UC c=UC,UC cnt=870 col 0264D4B4 r=0 a=0,0 c=0,UC cnt=871 col 0264D4B4 d=0,0 col 0264D50C r=0 a=0,0 c=0,UC cnt=872 col 0264D50C d=0,0 colG 0264D368 d=0,0 rowG 0264B3F0 r=2 a=2970,UC c=2970,UC cnt=873 row 0264B598 r=2 a=2970,UC c=2970,UC cnt=874 cell 0264CA8C r=2 a=510,UC c=450,UC cnt=875 block 0264CB30 r=2 a=450,UC c=450,UC cnt=876 place 0264CF60 r=2 a=450,UC c=UC,UC cnt=877 place 0264CF60 d=0,0 img 0264CEE0 r=2 a=450,UC c=450,450 cnt=878 img 0264CEE0 d=450,450 text 0264CFC4 r=2 a=450,450 c=UC,UC cnt=879 text 0264CFC4 d=330,285 block 0264CB30 d=450,450 o=(0,0) 780 x 450 <<<< previously to small reported mew gives an overflow, note that before the removal of the NS_BLOCKWRAPSIZE the table cell would have stretched to cover the overflow cell 0264CA8C d=510,510 cell 0264D0C8 r=2 a=2370,UC c=2310,UC cnt=880 block 0264D16C r=2 a=2310,UC c=2310,UC cnt=881 block 0264D16C d=2310,300 cell 0264D0C8 d=2370,360 row 0264B598 d=2970,510 rowG 0264B3F0 d=2970,510 colG 0264D368 r=2 a=2970,UC c=2970,UC cnt=882 col 0264D4B4 r=0 a=0,0 c=0,UC cnt=883 col 0264D4B4 d=0,0 col 0264D50C r=0 a=0,0 c=0,UC cnt=884 col 0264D50C d=0,0 colG 0264D368 d=0,0 tbl 0264B218 d=3000,600 tblO 0264B0A8 d=3000,600
What causes the nowrap to be ignored in that case?
*** Bug 208930 has been marked as a duplicate of this bug. ***
*** Bug 209133 has been marked as a duplicate of this bug. ***
*** Bug 209762 has been marked as a duplicate of this bug. ***
Priority: -- → P2
Target Milestone: --- → Future
Future? Bummer! Seems like people know what's wrong and recognize that this is a major bug. I certainly think it's annoying. Since this used to work in 1.3, isn't there anything that can be done to get this to work again before 1.4 final ships?
Maybe something related with this bug has changed between 1.4RC2 and 1.4RC3 In fact on the page http://www.netbeans.org/ the tabbed panes (which are created by a table) looks wrongs due to a text overflow on the right of each cell with 1.4RC2 but looks very well with 1.4RC3.
I noticed this too. Actually it looks like Netbeans "fixed" their page. It now no longer has a problem in rc2 (last I checked). The test cases still seem broken, so I don't think this bug has been fixed.
*** Bug 199206 has been marked as a duplicate of this bug. ***
Bug 199206 has some interesting comments/testcases.
Hi, ist there any progress here? This bug appeared after Mozilla 1.3 and continues till 1.5. Is there any way to fix it? It's really annoying that in a newer version a bug appeared.... ;-(( Thanks, Matthias
*** Bug 356255 has been marked as a duplicate of this bug. ***
Assignee: layout.floats → nobody
QA Contact: ian → layout.floats
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3

Not clear if there's a real bug here at this point. The testcases use images that are now 404 (which makes it behave slightly differently than intended); but if I adjust e.g. Mats' "testcase 2" (attachment 124320 [details]) to use https://placekitten.com/50/50 for its images, I get the same rendering between Firefox and Chromium.

And our current rendering (of that tweaked testcase) goes back at least a decade; Nightly 2012-01-01 matches current Nightly.

Not sure if there was a different rendering 19 years ago when this was filed vs. if the current rendering was considered wrong at that point; but it seems interop is in favor of our current rendering here. So, closing this as "incomplete" at this point, since it's not clear precisely what was broken or how it was broken (no screenshots unfortunately).

If there's a still-valid bug here that needs tracking/fixing, feel free to reopen with more details.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: