70998 - [FIX]Drop-down list width increases forever

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Conor Lennon]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.9) Gecko/20010305
BuildID:    2001030505

The first drop-down list on http://www.dmgdirect.com/ keeps getting wider until
the Stop button is pressed.


Reproducible: Always
Steps to Reproduce:
Go to http://www.dmgdirect.com/

Actual Results:  Drop-down list keeps getting wider

Expected Results:  Drop-down list doesn't get wider

Comment 1

[ivo]

Attachment: testcase

Comment 2

[ivo]

I experience same behaviour. 
Win98, Mozilla Build ID: 2001030205

Comment 3

[Conor Lennon]

The width of the drop-down list in the attachment does not increase for me.

Comment 4

[ivo]

If You mean automatic increase then it is not increasing, but make some
selections from that list.

Comment 5

[ivo]

This automatic increase does not occure if loading of images for this site is
disabled: go over some image on that site and right mouse button click and from
that menu "block image from loading" (strange but this operation prevents all
images ever loaded from that site in the future, to enable again
Preferences->Advanced->Images->View Image Permissions and remove this site from
list).
Increase only happens during image/data load/rendering.
(I try to upload a testcase showing it.)

Comment 6

[ivo]

Attachment: this is this .gif

Comment 7

[ivo]

Attachment: New testcase with automatic increase drop.list.

Comment 8

[ivo]

I see this bug on Linux, too.
Mozilla Build ID: 2001021806

Comment 9

[ivo]

This automatic increase has something to do with "position:absolute" and "width"
what must be less than 164px. This (automatic) increase happens every time there
is a image show (.gif and .jpg work same, but animated .gif will show automation).

Comment 10

[ivo]

Attachment: another testcase

Comment 11

[James Paige]

This is probably related to bug 64350 and bug 63910

Comment 12

[ivo]

This 164 is for Win98, but Linux has 194 for the same purpose in case of
multiple drop-down lists, so I think other platforms have their own magic number.

Comment 13

[ivo]

If this bug is related to these other then likely it is somesort of "repaint"
(or what to call it) problem when these lists lose track of their size.

Comment 14

[Vladimir Ermakov]

QA Contact Update

Comment 15

[ivo]

This 164 (194) is the size of this type of element (Mozilla will always display
these elements just the same size although width/height are different). 
It seem to be invalid implemention of standard.

Comment 16

[James Green]

Seen on Linux build from yesterday. Confirming, setting OS/All.

Comment 17

[rods (gone)]

The problem is the DIV is narrower than the combobox and therefore the 
availableWidth in the reflow state is not unconstrained. Then for whatever 
reason the combobox gets an unconstrained reflow after the incremental 
reflow. This causes the reflow logic to go down path that probably wasn't test 
before. 

Because if you make the DIV wider than the combobox or take out the explicit 
width of the div, it works fine.

Here is a possible patch that will take some additional testing/investigation:

Index: nsComboboxControlFrame.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/forms/src/nsComboboxControlFrame.cpp,v
retrieving revision 1.164
diff -u -r1.164 nsComboboxControlFrame.cpp
--- nsComboboxControlFrame.cpp	2001/02/23 01:45:44	1.164
+++ nsComboboxControlFrame.cpp	2001/03/09 16:19:50
@@ -1233,9 +1233,7 @@
   nsHTMLReflowMetrics dropdownDesiredSize(nsnull);
 
   // Check to see if this a fully unconstrained reflow
-  PRBool fullyUnconstrained = firstPassState.availableWidth == 
NS_UNCONSTRAINEDSIZE &&
-                              firstPassState.mComputedWidth == 
NS_UNCONSTRAINEDSIZE && 
-                              firstPassState.availableHeight == 
NS_UNCONSTRAINEDSIZE &&
+  PRBool fullyUnconstrained = firstPassState.mComputedWidth == 
NS_UNCONSTRAINEDSIZE && 
                               firstPassState.mComputedHeight == 
NS_UNCONSTRAINEDSIZE;
 
   PRBool forceReflow = PR_FALSE;

Comment 18

[ivo]

Now different width will give same size.
Does this width adjustment on drop-down list mustn't work at all?
What HTTP standard say about this?

Comment 19

[rods (gone)]

What does the standard say about what?

Comment 20

[ivo]

Is this width/height adjustment allowed at all?

Comment 21

[ivo]

There is a problem with selection inside drop-down list, linesize of selection
is as long as text, but it should be as long as list width.
I attach pictures about this. 

Comment 22

[ivo]

Attachment: drop-down list with 2001030205

Comment 23

[ivo]

Attachment: Drop-down list with 200131008

Comment 24

[ivo]

Increasing is back...

Win98 Build ID 2001031304

Comment 25

[rods (gone)]

Easy to test, testcase:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=31971

Comment 26

[rods (gone)]

*** Bug 75777 has been marked as a duplicate of this bug. ***

Comment 27

[rods (gone)]

Attachment: simple patch that needs a lot of testing

Comment 28

[rods (gone)]

I went through a bunch of the top sites and compared reflow counts and they came 
up the same. So it appears this does not increase the number of reflows.

Comment 29

[Marc Attinasi]

I don't understand what this change is doing - can you explain how it fixes the
problem? Thanks.

Comment 30

[rods (gone)]

The place it is used is:
  // If this was a fully unconstrained reflow we cache 
  // the combobox's unconstrained size
  if (fullyUnconstrained) {
    mCachedUncComboSize.width = aDesiredSize.width;
    mCachedUncComboSize.height = aDesiredSize.height;
  }

It determines whether the reflow size is cached, and we do not what the 
avialable size to play into whether the values are cached. So basically we will 
be caching the sizes more often and reusing them. If anything it should reduce 
the number of reflows (but I didn't see much change).

Comment 31

[Marc Attinasi]

sr=attinasi

Comment 32

[Kevin McCluskey (gone)]

r=[e-mail]

Comment 33

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

a=dbaron for trunk checkin (on behalf of drivers)

Comment 34

[rods (gone)]

fixed

Comment 35

[Vladimir Ermakov]

verifying build 2001-06-13-09-trunk windows 98