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)

x86
Windows Vista
defect
Not set
normal

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.
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.
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.
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.
(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.
Re-opening this bug and adding Boris to the CC list as per his request.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
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 ago16 years ago
Resolution: --- → DUPLICATE
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!
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.