650147 - When selecting all elements in a select form, the ui (browser) stops responding (pauses, halts, freezes, unresponsive, nonresponsive)

Status: NEW

(Core :: General, defect)

Description

[Matt]

Attachment: testcase

If you open this testcase and select the shown field, then hit SHIFT-END to select all elements in the field, the browser will become unresponsive until it is finished (about 10-15 seconds for me).

STR:
1. New profile
2. Open testcase
3. Select the labeled field (first on the left)
4. Hit SHIFT-END

Result:
Browser will be unresponsive while computing.

Desired Result:
Browser remains responsive while computing.  Perhaps compute faster also.


This is broken on trunk and shouldn't be a regression (it didn't work in the beginning of 2008).  

Broken:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008010104 

Broken:
Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110414 Firefox/6.0a1

Comment 1

[Matt]

Attachment: testcase

Oops.  Here it is as a html page.  I will get a profile of this.

Comment 2

[Matt]

Attachment: testcase_harder

Same as before but more options.  Much harder lockup.

Comment 3

[Matt]

Attachment: profile_testcase_harder

Profiled "testcase_harder".  Set dom.max_script_run_time = 60 to disable the script stopping popup.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> Browser remains responsive while computing.

That sort of needs separate content processes.  Working on that.

> Perhaps compute faster also.

Looking at a profile of this, looks like the script on the page is running the setSALoc function.  This function does a loop over all the items in the first select, then for each selected item (that is, for all of them) does a loop over every single item in the second select.  In this case, that means the inner loop gets hit about 10 million times.

Furthermore, the code is written to be as slow as possible (undeclared variables inside with, repeated gets for the same thing off the with, etc, etc).  So each iteration is not all that fast (compared to how fast it could be, at least.  I don't think it's worth worrying about speeding up this code; it hangs in all browsers I have on hand.

Comment 5

[Matt]

So should it block bug 516518 (Electrolysis) or bug 516752 (Electrolysis for Firefox)?  I looked over their blockers but it is not apparent to me where this could fit in...

Comment 6

[Boris Zbarsky [:bzbarsky]]

Other way around.  This bug (or at least the "don't lock up the UI" aspect of it) depends on bug 516752.

That said, it sounds like the slow script dialog is at least working as expected....

Comment 7

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: Stress Test

Adding stress test from http://www.mkyong.com/boring/google-chrome-vs-firefox-3-crash-stress-test/ for testing proposes

Comment 8

[Boris Zbarsky [:bzbarsky]]

That attachment has nothing to do with this bug.