Tables with cells and specified width causing incorrect table layout: text wrap (amazon.com)

RESOLVED FIXED in Future

Status

()

Core
Layout: Tables
P3
normal
RESOLVED FIXED
16 years ago
11 years ago

People

(Reporter: /\/\arcio Galli, Unassigned)

Tracking

({testcase})

Trunk
Future
x86
All
testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 3 obsolete attachments)

(Reporter)

Description

16 years ago
Tested with:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020211

I will file the testcase.
(Reporter)

Comment 1

16 years ago
Created attachment 68915 [details]
Two tables Testcase. The first case is the incorrect, the second is the correct expected behavior - this was created from real case: amazon.com product item pages.

Note in the first testcase that the second TD element have width="1". 

In the second testcase, I removed the width="1" from the table cells. Note that
the contents of the 3rd cell is not wrapping in the second testcase.
(Reporter)

Comment 2

16 years ago
Real case example:
http://www.amazon.com/exec/obidos/ASIN/0439286115/qid=1013464426/sr=5-2/ref=cm_lm_asin/104-0792733-2179912
Note that there is an extra white space on top of the table with two images of
the book covers. That happens because the text in the right side is wrapped. 
(Reporter)

Updated

16 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Updated

16 years ago
Summary: Tables with cells and specified width causing incorrect table layout: text wrap. → Tables with cells and specified width causing incorrect table layout: text wrap (amazon.com)
(Reporter)

Comment 3

16 years ago
This also happens with Win98.
OS: Linux → All

Updated

16 years ago
Target Milestone: --- → mozilla1.2
HTML tables.
Assignee: attinasi → karnaze
Component: Layout → HTMLTables
QA Contact: petersen → amar

Updated

16 years ago
Keywords: testcase
Priority: -- → P3
(Reporter)

Comment 5

16 years ago
Created attachment 69544 [details]
Testcase 2. When contents of 1st column are bigger than its specified width, 2nd column is affected (wraps content).

This testcase is much better. It's basically the following figure. 

+---------------+----------+-----------+
| width=100	| no width | width=50% |
| ............. | .........| ......... |
| img(width>100)| wraps    |	       |
|		| content  |	       |
+---------------+----------+-----------+
When the content of the 1st column is bigger than the TD specified width, it
affects the second column causing contents to wrap. This also happens with text
content in the first column. You can add a text content like the word 'M'. If
you gradually decrease the width of the TD (1st column), at some point the 2nd
column will wrap. This some point matches with the width size of the word 'M'.

Comment 6

16 years ago
Works for me with 20020818 build.
Reporter, can you test it with the latest build?

Comment 7

15 years ago
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: mozilla1.2alpha → ---

Updated

15 years ago
Target Milestone: --- → Future

Comment 8

15 years ago
This bug is still open.  Marcio Galli, could you please verify that the problem
no longer exists for you?  It was reported as working OK back in August, and it
still seems to work for me with 1.4a.
I'm seeing the problem with today's build... It looks like the columns for the
first table get widths based on declared or intrinsic sizes, then the second
column has to get wider and instead of rebalancing the whole table we just make
the third column narrower, since it has give....

It would make more sense to adjust the total table width, I'd think.

Comment 10

11 years ago
Testcases wfm.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070221 Minefield/3.0a3pre
Fixed by reflow branch, looks like.  We should add reftests...
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Depends on: 300030
Flags: in-testsuite?
Resolution: --- → FIXED
Created attachment 257299 [details] [diff] [review]
Reftests

Go ahead and check them in if you're happy with them (note that reftest.list in the patch assumes that the reftests in bug 105030 have already been checked in ;-)...)
Attachment #257299 - Flags: review?(bzbarsky)
Comment on attachment 257299 [details] [diff] [review]
Reftests

There's no 124903-1-ref.html in this diff.
Attachment #257299 - Flags: review?(bzbarsky) → review-
Created attachment 257302 [details] [diff] [review]
Reftests take 2

Whoops, sorry about that.
Attachment #257299 - Attachment is obsolete: true
Attachment #257302 - Flags: review?(bzbarsky)
Created attachment 257303 [details] [diff] [review]
I quit

Stupid stupid stupid...
Attachment #257302 - Attachment is obsolete: true
Attachment #257303 - Flags: review?(bzbarsky)
Attachment #257302 - Flags: review?(bzbarsky)
Comment on attachment 257303 [details] [diff] [review]
I quit

Put that image in a separate file so it's obvious that they're including the same thing, and r=bzbarsky.
Attachment #257303 - Flags: review?(bzbarsky) → review+
Created attachment 257325 [details] [diff] [review]
Same patch as before, using solidblue.png

Carrying over r+ from before
Attachment #257303 - Attachment is obsolete: true
Attachment #257325 - Flags: review+
Whiteboard: [checkin needed]
Checked in the test.
Flags: in-testsuite? → in-testsuite+
Whiteboard: [checkin needed]
You need to log in before you can comment on or make changes to this bug.