237159 - {inc} fieldsets report too large maximumWidth.

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Tomas Creemers]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040311
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040311

On http://lumumba.luc.ac.be/~nocturnal/testfacility/test.html , when pressing
the update button, it moves. (no javascript involved)

Reproducible: Always
Steps to Reproduce:
1. Go to http://lumumba.luc.ac.be/~nocturnal/testfacility/test.html
2. Click the button.
3. Try to catch it.

Actual Results:  
The button moved...

Expected Results:  
Stay, button, STAY!

On http://lumumba.luc.ac.be/~nocturnal/testfacility/test.html (which is a
stripped down version of
http://lumumba.luc.ac.be/~nocturnal/testfacility/gallery/?textmode=1 )
when I click the "update" form submit button, it moves to the left, while it
should stay put. The button does get the "pressed in" look.
Also, when I click the button and hold, and then move the mouse around, it moves
even more (when not at the most left position) (this is more obvious at
http://lumumba.luc.ac.be/~nocturnal/testfacility/gallery/?textmode=1 )
I use no javascript, and no CSS either on the testpage...

Comment 1

[Jesiah S]

I seen this before in other bugs.  I see this on LInux 2004041207

Comment 2

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

Attachment: reporter's testcase

Comment 3

[Dylan Tack]

Another example of this bug:
http://www.river-city-housing.org/
The submit button at the top moves when clicked.  The page is valid 4.01
transitional.

User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10.1

Comment 4

[Bernd]

Attachment: reduced testcase

Comment 5

[Bernd]

             button 023A6B88 d=804,264 me=804
             button 023A6B88 d=804,264 me=804
            area 023A68D4 d=804,264 me=804 m=804
           FieldSet(fieldset)(0) 023A6880 d=6984,523 me=1092 m=6984
the m value should be the same value as it reported as desired size during the
unconstrained initial reflow (1092):            
           button 023A6B88 d=804,264 me=804
          area 023A68D4 d=804,264 me=804
         FieldSet(fieldset)(0) 023A6880 d=1092,523 me=1092

Comment 6

[Bernd]

http://lxr.mozilla.org/seamonkey/source/layout/html/forms/src/nsFieldSetFrame.cpp#601
is plain wrong

600     aDesiredSize.descent = 0;
601     aDesiredSize.mMaximumWidth = aDesiredSize.width;
602     if (aDesiredSize.mComputeMEW) {
603 

Comment 7

[Bernd]

I should be able to fix this

Comment 8

[Bernd]

Attachment: patch

Comment 9

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

Comment on attachment 161184 [details] [diff] [review]
patch

I think you should check if (aDesiredSize.mFlags & NS_REFLOW_CALC_MAX_WIDTH)
before reading the child's mMaximumWidth, since otherwise you'll be reading
uninitialized memory.

Also, did you check that the inclusion of the legend is enough -- do you need
to worry about any border/padding there?

Comment 10

[Bernd]

Attachment: revised patch

I also removed that debug stuff,  which is now completely handled by the frame
reflow log
(http://lxr.mozilla.org/seamonkey/source/layout/doc/frame_reflow_debug.html)

Comment 11

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

Comment on attachment 161676 [details] [diff] [review]
revised patch

>+    if (aDesiredSize.mFlags & NS_REFLOW_CALC_MAX_WIDTH) {
>+      aDesiredSize.mMaximumWidth = PR_MAX(aDesiredSize.mMaxElementWidth, mLegendRect.width +
>+                                          borderPadding.left + borderPadding.right);
>+    }

In the previous patch, this was a PR_MAX of aDesiredSize.mMaximumWidth and
aDesiredSize.mMaxElementWidth.	I think you replaced the wrong half with the
legend expression.  r+sr=dbaron if what you meant to do here was
PR_MAX(aDesiredSize.mMaximumWidth, ...)

Comment 12

[Bernd]

fix checked in