Closed Bug 183918 Opened 17 years ago Closed 10 years ago

Performance awful: changing component in Bugzilla query


(Core :: Layout: Form Controls, defect)

Not set





(Reporter: typrase, Unassigned)




(Keywords: perf)

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

Reproducible: Always

Steps to Reproduce:
Try Bugzilla/Issuezilla query pages such as the following:

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:

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.
Keywords: 4xp, perf
there was a major speedup for this very issue a year ago: bug 53165.
This has nothing to do with the JS engine.
Assignee: rogerl → form
Component: JavaScript Engine → Layout: Form Controls
QA Contact: pschwartau → tpreston
*** Bug 184023 has been marked as a duplicate of this bug. ***
The performance is still poor (compared with Opera 7.52 for example)
Ever confirmed: true
Summary: JavaScript performance awful: changing component in Bugzilla query → Performance awful: changing component in Bugzilla query
Assignee: layout.form-controls → nobody
QA Contact: tpreston → layout.form-controls WFM
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091122 Minefield/3.7a1pre
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.