Closed Bug 381130 Opened 15 years ago Closed 13 years ago

Small changes to line layout for new textframe

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: roc, Assigned: roc)

Details

Attachments

(1 file)

Attached patch patchSplinter 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+
I landed this (and added the reftest) long ago.
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.