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.

This isn't the way line layout works.

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.

Fixed by the checkin to bug 131023.

Marking fixed.