Closed
Bug 381130
Opened 18 years ago
Closed 17 years ago
Small changes to line layout for new textframe
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: roc, Assigned: roc)
Details
Attachments
(1 file)
9.02 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
I have a patch with the following small changes:
1) add nsGkAtoms::tabWidthProperty that new textframe will be using. Trivial.
2) Add nsLineLayout::GetCurrentFrameXDistanceFromBlock. This is needed by the new textframe's tabbing code to figure out where the tab stops are.
3) A bug fix for inline layout. If a text frame doesn't fit on a line, but it registers a break opportunity at its end, and that's the only break opportunity on the line, nsLineLayout::CanPlaceFrame decides that it's OK to push the frame because there is a break opportunity to roll back to ... not realizing that the break opportunity is in the frame, not before it, so that strategy won't work. The fix is simple, tell CanPlaceFrame whether there was a break opportunity before the current frame. The testcase is this:
<div style="width:1px;"><span>Trythis</span>whynot?
</div>
The bug caused it to break after the span. I can add a simple reftest to this effect.
Attachment #265212 -
Flags: review?(dbaron)
Comment on attachment 265212 [details] [diff] [review]
patch
r=dbaron. (Might be good to run the rest of the reftests in case you're causing any unexpected passes -- does this affect the known (regression) failures of the Japanese breaking reftests?)
Attachment #265212 -
Flags: review?(dbaron) → review+
Assignee | ||
Comment 2•17 years ago
|
||
I landed this (and added the reftest) long ago.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•