Closed Bug 373295 Opened 18 years ago Closed 17 years ago

min width computation broken for text split between two text nodes when first is continuation

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha8

People

(Reporter: jruderman, Assigned: roc)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files)

testcase (text should not overlap border; should match reference)
(deleted), text/html
Details
reference
(deleted), text/html
Details
I found this bug by making dynamic changes to layout/reftests/bugs/351641-1a.html.
Attached file reference (deleted) —
Regressed between 2006-12-07 and 2006-12-08, perhaps due to the reflow branch landing.
Blocks: reflow-refactor
Keywords: regression
Flags: blocking1.9?
looks like the minwidth change does not get propagated
No, it looks like we have problems computing min width for an unwrappable piece of text split between two separate text frames.
From stepping through in the debugger, CanBreakBetween is returning true, which is a lie.
Component: Layout: Tables → Layout: Fonts and Text
QA Contact: layout.tables → layout.fonts-and-text
Summary: <table width="1"> does not expand to accomodate added text, causing text to overlap table border → min width computation broken for text split between two text nodes
Assignee: nobody → roc
...which is because AddInlineMinWidth is designed to process all continuations at once, but CanBreakBetween looks at the offset/length of the particular continuation passed in (which in AddInlineMinWidth is always the first). So it's determining that yes, we can break between "abc " and "ghi", but that's not what we want to be asking.
Summary: min width computation broken for text split between two text nodes → min width computation broken for text split between two text nodes when first is continuation
Blocks: refdyn
Blocks: 375827
Flags: blocking1.9? → blocking1.9+
Target Milestone: --- → mozilla1.9alpha6
Works for me in a new-textframe build. It doesn't block new-textframe, but depends on it...
No longer blocks: 333659, 375827
Depends on: 333659
punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.
Target Milestone: mozilla1.9alpha6 → mozilla1.9beta1
WORKSFORME?
FIXED by new textframe landing, actually.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
reftest checked in.
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: