Closed
Bug 503781
Opened 16 years ago
Closed 16 years ago
Website with large form (1000 choices) causes Minefield to hog CPU and quit responding.
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 477564
People
(Reporter: geeknik, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090712 Minefield/3.6a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090712 Minefield/3.6a1pre
The website linked in this bug has approximately 1000 or so choices in it's form and it causes Minefield build 20090712042756 to hog the CPU and quit responding. I tested this in safe mode as well and I thought it was going to work as it loaded the page and I could scroll to the bottom and back to the top and then it quit responding. Page loads with no issues in IE8 or Chrome 3.x.
Reproducible: Always
Steps to Reproduce:
1. Open Minefield
2. Visit http://www.nws.noaa.gov/tdl/synop/products/bullform.all.php
Actual Results:
Minefield hogs the CPU and quits responding.
Expected Results:
Minefield should load the page normally and allow me to interact with the form with no problems.
Can you please check the testcases in bug 146468 and bug 115388 to be sure they don't cause the same problem, otherwise this is a dupe of one of them.
or bug 277123
| Reporter | ||
Comment 3•16 years ago
|
||
Bug 146468 testcase is dead. Bug 115388 testcase doesn't cause the same problem if I set it to 1000 like the URL I submitted. Bug 277123 pretty much kills the browser immediately.
Updated•16 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
I would mark this as duplicate of bug 498868.
I was able to reproduce this with FF3.5 with the noaa site. Sudden hang, when scrolling down (so, no performance issue). I will copy that data to 498868.
| Reporter | ||
Comment 6•16 years ago
|
||
I have to disagree with this being marked as a duplicate of Bug 477564. I'm following that bug and this isn't a session restore issue because the browser is open when this happens. If anything, it's a duplicate of bug 277123 as per Mardeg.
Comment 7•16 years ago
|
||
(In reply to comment #6)
What needs time isn't restoring a page with a large form but saving its state (in case a restoration is later needed). Also note that if Firefox 3.0.11 doesn't have the same issue, this can't be any of those older bugs.
| Reporter | ||
Comment 8•16 years ago
|
||
Re-opening this bug and adding Boris to the CC list as per his request.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 9•16 years ago
|
||
I can't reproduce this issue when setting browser.sessionstore.privacy_level to 2, so this really is bug 477564.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → DUPLICATE
Comment 10•16 years ago
|
||
bug 486468, bug 488156, bug 491369, bug 492728, bug 498991, bug 499981, bug 500535, bug 501582, bug 501695, bug 501951, bug 502007, bug 502639, bug 503394, bug 503563 and bug 498868, are all marked duplicate of bug 477564 and none of these duplicates talk about session restore!
Comment 11•16 years ago
|
||
Lucas, the bug in question manifests when session restore is _saving_ information to restore, not when it's restoring it. So from a user's point of view, there is no session restore going on, so it won't be mentioned in the bug's initial filing
The test Simon did in comment 9 is the conclusive test for whether a bug is a duplicate of bug 477564.
You need to log in
before you can comment on or make changes to this bug.
Description
•