Closed Bug 286257 Opened 15 years ago Closed 5 years ago

Large/long <select> option list is slow when option strings large

Categories

(Core :: Layout: Form Controls, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: tony.cleverley, Unassigned, NeedInfo)

References

Details

(Keywords: testcase, Whiteboard: [reflow-refactor])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2

A large select list say 9000 options. Each option has associated text sting that
is around 100 charatcers long. The page can take over 2 minutes to load. The
corresponding page on IE is < 2 seconds to load.

The CPU is running at 100% while it tries to load the page

Reproducible: Always

Steps to Reproduce:
1. Save attachement to file
2. Load file in Firefox
3. Page display select box some 2 minutes later

Actual Results:  
Long time to load page

Expected Results:  
Page should load in less than 2 seconds and be faster than IE.
Example of of select list problem - unzip file and load
With a current trunk build, that takes about 20 seconds... most of the time is
spent in text-measurement and such (which is needed to find the right size for
the <select>).
Whiteboard: [reflow-refactor]
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Keywords: testcase
Should re-profile this once the new textframe lands.
Status: UNCONFIRMED → NEW
Depends on: 333659
Ever confirmed: true
This testcase loaded pretty much instantaneously for me (today’s nightly build, OS X 10.9 on a 2010 imac). Suggest INVALID now.
In that case, it is WFM, because it used to be a problem. Not anymore according to comment 5.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
On Windows 7 SP1 the attached test case takes 8-10 seconds with Firefox CPU usage climbing to 53%. Tested 10 times.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
AMD Phenom II X2 550 3.10 GHz
I can confirm this is still a problem. Where I work, we have a corporate intranet with some truly colossal <select> elements - think 50,000 or so options. While I agree this is terrible, it's on a system that can't currently change right now.

Firefox, on this particular site, sits there for up to a minute on my MacBook Pro 2015 Model, whereas Chromium is able to open the menu in less than 10 seconds.

Our use case is decidedly nonstandard, but this is still an area where Firefox has a disadvantage compared to Chromium/Chrome.

For reference, the test case attached to this bug ("blah.html") opens in around 2.5 seconds on Firefox 51 x64 on Windows on an Intel Core i7 6700 non-OC, whereas it is instant on Chrome on the same hardware.

If there is no activity on this, I would be interested to take this on as a first bug fix.
Same Problem here, on our Site the Select is extreme slow (FF Version 59.0.3), it takes nearly 10 seconds to open the dropdown, in Chrome the list opens instant.
Site to test the issue:

https://www.luftballon-markt.de/luftballons/luftballons-oe-15cm-standard/11196/100-luftballons-oe-15cm-gelb
Tested in FF 52 -> dropdown is nearly instant! Please fix...
Flags: needinfo?(tony.cleverley)
I also have the same problem on FF 60 on Ubuntu 18.04 64 bits.

In the attached file:
- it takes about 8 seconds in FF to open
- whereas it opens in 1.5 seconds on Chrome

In a real world example, on http://www.addic7ed.com/, the quick search dropdown list:
- takes about 4 seconds in FF to open
- whereas it is immediate on Chrome
You need to log in before you can comment on or make changes to this bug.