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

Status: REOPENED

(Core :: Layout: Form Controls, defect)

Description

[Tony Cleverley]

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.

Comment 1

[Tony Cleverley]

Attachment: Html that takes long time load

Example of of select list problem - unzip file and load

Comment 2

[Boris Zbarsky [:bzbarsky]]

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>).

Comment 3

[Gervase Markham [:gerv]]

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/

Comment 4

[Boris Zbarsky [:bzbarsky]]

Should re-profile this once the new textframe lands.

Comment 5

[Robin Whittleton]

This testcase loaded pretty much instantaneously for me (today’s nightly build, OS X 10.9 on a 2010 imac). Suggest INVALID now.

Comment 6

[Martijn Wargers (dead)]

In that case, it is WFM, because it used to be a problem. Not anymore according to comment 5.

Comment 7

[Carlos Alén Silva]

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

Comment 8

[Adam A]

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.

Comment 9

[linustentler]

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

Comment 10

[linustentler]

Tested in FF 52 -> dropdown is nearly instant! Please fix...

Comment 11

[amanteaux]

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

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.