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

NEW
Unassigned

Status

()

defect
8 years ago
4 years ago

People

(Reporter: mdinger.bugzilla, Unassigned)

Tracking

({testcase})

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 1 obsolete attachment)

Reporter

Description

8 years ago
Posted file testcase (obsolete) —
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
Reporter

Comment 1

8 years ago
Posted file testcase
Oops.  Here it is as a html page.  I will get a profile of this.
Attachment #526133 - Attachment is obsolete: true
Reporter

Comment 2

8 years ago
Posted file testcase_harder
Same as before but more options.  Much harder lockup.
Reporter

Comment 3

8 years ago
Profiled "testcase_harder".  Set dom.max_script_run_time = 60 to disable the script stopping popup.
> 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.
Reporter

Comment 5

8 years ago
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...
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....
Depends on: e10s
That attachment has nothing to do with this bug.

Updated

4 years ago
No longer depends on: e10s
You need to log in before you can comment on or make changes to this bug.