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.