From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) BuildID: 2000080923 If you have a <select multiple> with 8000 options in Mozilla it becomes too slow to work with. Netscape 4.5 on the other hand doesn't have a problem whatsoever with this. Reproducible: Always Steps to Reproduce: 1.see description 2. 3. Actual Results: see description Expected Results: be alot more responsive <select multiple name="line_sel" size="3" class="linesbox"> <option value="all" selected>All <option value="57-555-0">555-0 <option value="58-555-1">555-1 <option value="67-555-10">555-10 <option value="157-555-100">555-100 <option value="56-555-1000">555-1000 <option value="1057-555-1001">555-1001 <option value="1058-555-1002">555-1002 <option value="1059-555-1003">555-1003 <option value="1060-555-1004">555-1004 <option value="1061-555-1005">555-1005 <option value="1062-555-1006">555-1006 ... and so on ... </select>

I think that this is a dupe. Moving over to html form controls. Reporter have you viewed with a more current build?

-> HTML Form Controls

Someone should profile this.

Also, someone please confirm with a newer build. Reporter: Please upload the source for the page as an attachment.

Yup seeing this on Mozilla Build #2000112704 M18 Trunk Build, Win 98, PC. I also lost the ability to type in the dialog boxes here as well and had to restart Mozilla.

I agree, but how useful is an select with 8000 options? I am sure this is a dup of other select performance bugs.

Setting milestone to future

QA Contact Update

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

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

Seeing this on win95, build 2001081108. http://www.burlco.lib.nj.us/moz/select/ contains a simple form with a select that contains 10000 option tags. (Would this ~260kb file have been too big to attach to this bug?) The following is a chart of page load times (in seconds) with an increasing number of option tags: 1000 - n/a 3.1 2000 - 5.4 5.3 3000 - 7.5 31.6 4000 - 9.7 55.5 5000 - 12.1 105.5 6000 - 14.1 156.0 7000 - 16.5 210.3 8000 - 18.7 270.3 9000 - 21.9 345.2 10000 - 25.1 415.8 The first column is the # of option tags in the page being loaded, the second column is the load time *when I increment the number of option tags by 1000 and click the reload button* and the third column is the load time *when I increment the number of option tags by 1000, click in the URL location bar and hit enter to reload the page*. Another weirdness is that, when I click in the URL location bar and hit enter to reload the page, then switch to another window that partially conceals the Mozilla window, the load time for the 10000-option-tag page falls back down to around 30 seconds, instead of the 'expected' 400 or so seconds (IE5.5 loads it in under 5 seconds). Hope this gives someone a clue.

Seems to be worksforme on Linux 2001092021. Please test on other platforms and resolve it.

Adding a "block" because this becomes bad again with my patch.

OK, selection is no longer dog slow on this HTML with the first bug 34297 patch. Now adding a dependency. Actually selecting the options by clicking on them, which I assume people are talking about, is almost instant at the beginning of the list and takes up to 1/3-1/2 second at the end of the list (due to the fact that the frame has to figure out what the option index is--and that's calculated by speeding through the array to find the option). Even without the patch, in current CVS, it only takes 2-3 seconds (1GHz Athlon, 256M RAM).

So is this dog slow or not? What is acceptable?

OK, selection now takes under a second on my *debug* build (so it's got to be a lot faster on the opt build). JST made a checkin tonight, in fact, that really cured it (removing a spurious GetIndex() from nsHTMLOptionElement::SetSelectedInternal(). The page takes longer to load now, but that's a bug 108232 issue, not an issue for here.

verified fixed on win2000 buildID: 2001-11-08-06-trunk mac 9.1 buildID: 2001-11-08-08-trunk