From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1) Gecko/20010607 BuildID: 2001060703 i experience quite slow performance in comparison with IExplore when i try to change the products in the products list in the sample url. iexplore for example does fine and fast change the entries in the drop down box ;) Reproducible: Always Steps to Reproduce: 1.choose for example "Browser or Editor (aka Composer)" 2.choose for example "Language Packs or Localized Builds" 3.wait Actual Results: delay Expected Results: faster performance in addition there are empty entries in the list (nonsense?)

Confirming on 2001060120 Win2k. Adding perf keyword and depedency, over to DOM Level 0.

rods yesterday checked in a re-write of the select widget code, suppressing reflows whilst the list items were being modified, which has shaved a lot of time off the selection. However it is still too slow, which may be attributed to another component entirely, such as this DOM0. I'm pretty sure the remaining issues are covered by other bugs but I wouldn't like to pinpoint them. dbaron I think said that on linux at least, the security manager kicks in and causes us some delay - am I right in thinking that affects this too?

how do you mean - security manager? it actually works fine without any error messages!

I doubt the security manager code accounts for much of the slowdown...

I believe dbaron said that on profiling Javascript Dom stuff, he noticed (on linux, at least), that the security manager was continually kicking in and causing a slowdown (which wouldn't generate errors). I could be wrong.

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

Bug 97345 will probably help this. The bugzilla-helper probably needs a good kicking too.

Changing items in drop down boxes have become noticeably faster. The most evident example is http://bugzilla.mozilla.org/query.cgi , where changes to "Program" field were requiring up to 1 sec to modify "Component" items. Since September, those times were cut at least to 1/5th (too fast for using a stop-watch). They are still not instant (like in NS4.7) but the annoying large performance difference has gone.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

don't move bugs that are in the 1.0 dependency tree. sorry.

SEVERITY = LOW [(1)No Crash, (2)Resulting from some functional failure, (3)No Cosmetic failure] VISIBILITY = HIGH [(1)Failure is on mozilla.org so very high visibility. (2)Gets one point of compatibility with other browsers since it works very well on other browsers.] PRIORITY = VISIBILITY * SEVERITY Hence Priority = p3 adding word "qawanted" because I'm setting this priority on available data & if someone feels otherwise then please investigate this more & feel free to change this priority.

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

WFM with updated link: http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser&format=guided

WFM 2003010205, Windows XP. No delay at all to generate new content in dropdowns when selecting different products. (http://bugzilla.mozilla.org/query.cgi)

Verified - Moz 20020310 Win32.

s/20020310/20030103 of course. Sorry...