Tested with: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020211 I will file the testcase.
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.
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.
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)
This also happens with Win98.
OS: Linux → All
Assignee: attinasi → karnaze
Component: Layout → HTMLTables
QA Contact: petersen → amar
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'.
Works for me with 20020818 build. Reporter, can you test it with the latest build?
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: mozilla1.2alpha → ---
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.
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
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.
Created attachment 257303 [details] [diff] [review] I quit Stupid stupid stupid...
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
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.