381130 - Small changes to line layout for new textframe

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: patch

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?)

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I landed this (and added the reftest) long ago.