Closed Bug 145467 Opened 22 years ago Closed 22 years ago

nsLineBox always have mBounds.x == 0 (zero), even when the a short line is right aligned.

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: esben, Assigned: dbaron)

References

()

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
BuildID:    2002051009

When attempting to fix bug 1777, I found that querying nsLineBox.mBounds.x
always returned zero, even when the origin of the first child was not (0,y).
E.g., with a small line right aligned as in
http://bugzilla.mozilla.org/attachment.cgi?id=81294&action=view , the lineBox
has mBounds=(0,y,width,height). This should IMHO be (x,y,width,height). In other
words, mBounds.x should equal firts child's Origins x-value.

Reproducible: Always
Steps to Reproduce:
1.Modify code to print out the LineBox's mBounds.x value, e.g. while
nsBlockFrame is Paint()'ing them.
2.compile & run
3.View the above testcase

Actual Results:  The value printed is 0

Expected Results:  The value should be somewhat large, and positive (dependent
on resolution among other things)

If bug1777 checks in with my patch before this is corrected,
nsBlockFrame::PaintTextDecorationLines should be recorrected to use the
mBounds.x value.
Priority: -- → P3
Target Milestone: --- → Future
This isn't the way line layout works.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Care to elaborate just a tiny bit? Otherwise David Baron will keep asking me why
I don't use the mBounds.x value. :o) It seems strange to me (and others) that a
member variable is identically zero at all times.
Well, if we combined the not-ifdef-IBMBIDI way of calling
nsLineLayout::HorizontalAlignFrames with the ifdef-IBMBIDI code inside of it,
this is the way line layout would work.  I really can't stand what bidi did to
that function (see bug 131023).
Well in that case, I think it should be fixed. I'm willing to give a hand, if
that helps.... anyways, moving over to bug 131023. Should this bug be marked as
dependant on bug 131023?
Ok, my bad. Reopen.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Fixed by the checkin to bug 131023.
Assignee: attinasi → dbaron
Status: REOPENED → NEW
Marking fixed.
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Depends on: 131023
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.