Closed Bug 363072 Opened 18 years ago Closed 18 years ago

[reflow branch][border-collapse] Table content unnecessarily wrapped

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ajschult784, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(10 files, 1 obsolete file)

testcase
(deleted), text/html
Details
Testcase #2a (Quirks mode)
(deleted), text/html
Details
Testcase #2b (Standards mode)
(deleted), text/html
Details
wip2
(deleted), patch
Details | Diff | Splinter Review
Testcase #3a (Quirks mode)
(deleted), text/html
Details
Testcase #3b (Standards mode)
(deleted), text/html
Details
Testcase #4a (Quirks mode)
(deleted), text/html
Details
Testcase #4b (Standards mode)
(deleted), text/html
Details
Testcase #5
(deleted), text/html
Details
Patch rev. 3
(deleted), patch
dbaron
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
With the reflow branch, I see text content unnecessarily wrapping in a table. The table should be wider to accommodate the content.
Attached file testcase (deleted) —
With the reflow branch, one of the "blah" wraps to the next line, but it shouldn't.
Confirming on Windows OK -> ALL.
OS: Linux → All
Hardware: PC → All
(In reply to comment #2) > Confirming on Windows OK -> ALL. > Hmmm. I obviously meant OS -> ALL.
Attached file Testcase #2a (Quirks mode) (deleted) —
Attached file Testcase #2b (Standards mode) (deleted) —
Summary: [reflow branch] Table content unnecessarily wrapped → [reflow branch][border-collapse] Table content unnecessarily wrapped
Attached patch wip (obsolete) (deleted) — — Splinter Review
This makes the layout of all the testcases the same as on trunk...
I'd think |aBorder.width| should already have that size in it.
Attached patch wip2 (deleted) — — Splinter Review
It seems so.
Attachment #247872 - Attachment is obsolete: true
I thought border was supposed to be the amount on the outside, fixed up in places like nsCSSOffsetState::InitOffsets (for other cases) nsTableFrame::IntrinsicWidthOffsets (in this case). Are you testing with different borders on the two sides?
(In reply to comment #9) > Are you testing with different borders on the two sides? More specifically, with an odd pixel border on the left and no border on the right, and then vice versa.
Maybe the problem is that nsCSSOffsetState::InitOffsets should be calling GetIncludedOuterBCBorder instead of GetExcludedOuterBCBorder?
Attached file Testcase #3a (Quirks mode) (deleted) —
Attached file Testcase #3b (Standards mode) (deleted) —
Attached file Testcase #4a (Quirks mode) (deleted) —
Attached file Testcase #4b (Standards mode) (deleted) —
Attached file Testcase #5 (deleted) —
Attached patch Patch rev. 3 (deleted) — — Splinter Review
(In reply to comment #11) > Maybe the problem is that nsCSSOffsetState::InitOffsets should be calling > GetIncludedOuterBCBorder instead of GetExcludedOuterBCBorder? Agree.
Attachment #250592 - Flags: superreview?(dbaron)
Attachment #250592 - Flags: review?(dbaron)
Comment on attachment 250592 [details] [diff] [review] Patch rev. 3 r+sr=dbaron
Attachment #250592 - Flags: superreview?(dbaron)
Attachment #250592 - Flags: superreview+
Attachment #250592 - Flags: review?(dbaron)
Attachment #250592 - Flags: review+
Checked in to trunk at 2007-01-05 07:38 PST -> FIXED
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: