Build ID: 1999082008 Platform: Windows NT (Behavior is OK on Linux; Mac OS build currently bad) To reproduce: - Launch apprunner - Load the above URL (Netscape internal only) or the attached test case - Drop down the drop-down list displayed on the page Result: It takes upwards of 3 seconds on a Pentium with MMX, 200 MHz, running Windows NT 4.0 SP 5. This is an unacceptable length of time. Note: This test page (which can be found it its original form at mozillazine.org) has 5 tables nested within each other. If you take the FORM out of the tables, performance is markedly improved. From the DOS window: 123 Position Dropdown at: 0 330 1110 480 nsComboboxControlFrame::Reflow 143 Reason: eReflowReason_Incremental nsComboboxControlFrame::Reflow 144 Reason: eReflowReason_Resize 124 Position Dropdown at: 0 330 1110 480 nsComboboxControlFrame::Reflow 145 Reason: eReflowReason_Resize 125 Position Dropdown at: 0 330 1110 480 nsComboboxControlFrame::Reflow 146 Reason: eReflowReason_Resize 126 Position Dropdown at: 0 330 1110 480 Warning - table cell content max element height 480 greater than desired height 360 nsComboboxControlFrame::Reflow 147 Reason: eReflowReason_Resize 127 Position Dropdown at: 0 330 1110 480 nsComboboxControlFrame::Reflow 148 Reason: eReflowReason_Resize 128 Position Dropdown at: 0 330 1110 480 Warning - table cell content max element height 480 greater than desired height 360 nsComboboxControlFrame::Reflow 149 Reason: eReflowReason_Resize 129 Position Dropdown at: 0 330 1110 480 nsComboboxControlFrame::Reflow 150 Reason: eReflowReason_Resize 130 Position Dropdown at: 0 330 1110 480 Warning - table cell content max element height 480 greater than desired height 360 nsComboboxControlFrame::Reflow 151 Reason: eReflowReason_Resize 131 Position Dropdown at: 0 330 1110 480

Troy, I believe the incremental reflow solution we talked about (involving the ability to say that nothing changed) will fix this since the table code is probably doing a bunch of pass 1 reflows.

I don't want to get stuck with this bug. Assigning to Kevin first to see if he can avoid doing a reflow in the first place. That's the real problem A seconday issue is optimizing table incremental reflow

Kevin, if we can't avoid the incremental reflow of the combo box frame, then you should assign the bug back to me, of course

After talking to Peter, there doesn't seem to be anyway that I can avoid doing an incremental reflow. All of the gfx form elements use style rules to control their appearance in the active state. The only way to tell if the button hasn't really changed size is to reflow it's children. Even if I were to do something special for the combo box button it would not solve the problem for other form elements such as HTML4 buttons. In their case, the style rules for active can apply both to the button and it's contents. There isn't anyway for the button to know whether its content will change size unless the active style rule has been applied to its children. Hopefully, the solution of returning whether the size actually changed during incremental reflow will improve combo boxes and other form elements performance when they are placed within nested tables. Troy, reassigning back to you. Troy, reassigning to you.

Changing platform etc. to ALL. Using the 19990914xx builds on Linux and Windows NT, performance is abysmal at (for example) my.yahoo.com. At My Yahoo!, I have my page customized to show Flight Reservations. In this section, there are drop-down lists of number of people, etc. On a 200 MHz Pentium running NT, it takes 12-15 seconds to drop down those lists. A 350 MHz Pentium II running Red Hat Linux 6 takes 10-12 seconds to drop down those lists. This is not good.

I need a real URL to test with. The simplified test case displays reasonably quickly for me, and I don't think that's a big problem As far as my.yahoo.com, I need something more concrete than a URL that I have to customize to reproduce the problem Please provide a suitable URL (or attachment) that demonstrates the problem

I agree. The original test case (attachment - poll.html) is a Win32 only problem. If you'd like to see the problem with My Yahoo!, I've created a sort-of version of that page for internal use only at http://schist/myy - try that on Linux and Win32; it should show the performance issue. Just click on the Total number of travellers thingy to select a number. It takes upwards of 15 seconds to show on a 200 MHz Pentium with MMX running NT.

Thanks for the test case. Yes, the performance is unbelievably horrible

Kevin, when I look at the simplified test case above I see that there are _six_ style changed reflow commands being generated starting from when I move over the combo box drop-down button. The first such reflow comamnd happens when the button is entered, _before_ I even click on the button. I think the first order performance issue here is the fact that six reflow commands is five more than should be generated I'm reassigning the bug back to you. When the number of reflow commands is reduced to something resonable (like one), if we still have a performance problem on pages with tables then reassign the bug back

I changed the hover border width to match the default border width and that got rid of the reflows that where happening upon entering the combo box button.Ther e are still two reflows generated when clicking on the combo box dropdown. These are caused by style rules which adjust the padding to make the button look depressed. (1 reflow for down, 1 reflow for up).

I can fix the performance problem by not setting the padding on the combobox dropdown button. I have the fix in my tree, just need permission to check it in. The general problem is that setting padding causes a reflow. The padding is needed to make buttons look "depressed". Troy and Peter are working on a optimization which will allow padding to be changed without generating a reflow if the overall dimensions of the content area does not change.

To remove combobox reflows I changed padding settings for the select's active button to match non-active state. I Also changed padding+border to match between button's with focus and active buttons drawn with focus. Added gif for active state of combo box to indicate that it is depressed. Still requires an optimization for collapse to prevent reflows from happening when the combo box button is clicked on. Peter, re-assinging to you.

This is the NS_STYLE_HINT_MOVE issue.

Accepting the bug again. I guess it was a mistake from gerardok. That bug should have never left my list.

Moving [DOGFOOD] in Status Summary to dogfood in keyword field.

This works pretty good for me with 2000021509. Marking WorksForMe.

Marking VERIFIED WORKSFORME on: - LinuxRH62 2000-09-07-08-M18 Commercial - Win98 2000-09-07-08-M18 Mozilla - MacOS86 2000-09-07-04-M18 Commercial