User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 Mozilla JavaScript performance when changing components in a Bugzilla query form is far far worse than that of Netscape Communicator 4.78 - significantly impeding use of the form. I did not find another bug specifically mentioning this form or forms like it. I saw several bugs mentioning poor JavaScript performance, but I do not know which specific aspect of the BZ query form is primarily responsible for the massive overhead - probably this is a duplicate of some existing bug report I was unable to identify. Bug #117611 seems to be the standard umbrella bug for this kind of issue. Reproducible: Always Steps to Reproduce: Try Bugzilla/Issuezilla query pages such as the following: http://www.netbeans.org/issues/query.cgi http://nagoya.apache.org/bugzilla/query.cgi Click on different "Component"s (resp. "Program"s). The rest of the display will update accordingly: different "Subcomponent"s (resp. "Component"s), different "Version"s, "Target Milestone"s, etc. In NS Comm 4.78, this update is essentially instantaneous. I believe that is true of other browsers as well (not sure though). In Mozilla (at least in 1.0, 1.1, and 1.2.1) each change in the component/program list requires about four seconds (!) of CPU processing on my machine (1.2 GHz processor). This is enough to cause my laptop fan to turn on every time I click on a new component. Using the keyboard to work with this form is out of the question; using arrow keys and Page Up/Down to navigate through the component list to the component you want would take at least a minute in practice. It is only tolerable to use the mouse to scroll down to the correct component and select it once. Selecting several components is painful since each one requires four seconds of waiting. Actual Results: Four second pause after every change in selection. Expected Results: Small pause (less than half a second) would be acceptable. Even if it were still a regression from the NS Comm performance levels, a tenfold speed increase would make the form much more usable.

Interestingly, this is not dogfood I suppose: http://bugzilla.mozilla.org/query.cgi is perfectly fast for me. Obviously some new version of Bugzilla did something which made performance dramatically better for Mozilla. The question remains why Mozilla performs so poorly on the older JavaScript.

there was a major speedup for this very issue a year ago: bug 53165.

This has nothing to do with the JS engine.

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

The performance is still poor (compared with Opera 7.52 for example)

http://netbeans.org/bugzilla/query.cgi?format=advanced WFM Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091122 Minefield/3.7a1pre