GNOME Bugzilla – Bug 480881
Firefox is very slow on pages with forms
Last modified: 2008-07-22 19:32:54 UTC
Hi, cursor motion is slow to the point of not being usable in pages with large forms. See for instance www.europarl.europa.eu -> english -> traineeships -> piad traineeships for people with a disability -> application form But I found it on others as well. Thanks for looking into it, Greetings, Rudolf
Hi Rudolf: Thanks for filing this bug! Can you tell us more about how you are navigating? Is this when using the arrow keys to move character-by-character, line-by-line, etc., or it is when using the structural navigation keys to move object-by-object? Will
Hi Will, thanks for looking into it. By now I think, that this is a general probelm in FF which just gets more extreme on pages with large forms. Using both u and U and the cursor keys takes about 0.3sec on a medium sized page. This is not quite fluent but still ok, if you read through a page slowly. When you are looking for something - and therefore press the cursor keys alot in a fast sucession - it is however already a bit long. On a large page, the delay is up to a second, which is too much even for normal reading. One such page is www.immobilienscout24.de. I'll send you an example of a slow html form by mail, because it should not be accessible from the net. Cheers, Rudolf
(In reply to comment #2) > Hi Will, > thanks for looking into it. > By now I think, that this is a general probelm in FF which just gets more > extreme on pages with large forms. Using both u and U and the cursor keys takes > about 0.3sec on a medium sized page. Thanks Rudolf! This helps narrow the scope of the problem to structural navigation. We have some work going on with bug 491837 that should hopefully be able to help with this. As work progresses on bug 491837, we can revisit this bug to see if it helped with performance.
I have some ideas on this one. Taking it from Scott. :-) Hope that's ok!
Created attachment 101884 [details] [review] patch to address some of the issues - take 1 Part of the slowness is due to how we get line contents (addressed in bug 500016). Part of the slowness is that find{Next,Previous}CaretInOrder() is not efficient (bug 506360). And then there's some other stuff, <smile> some of which I tried to get in this patch, some of which will hopefully result from Scott's work. Anyhoo.... Mike please give this one a spin, including on the bugzilla advanced search page. Note that there is still some sluggishness when moving to an entry that follows a combo box because the label guess code is still using the old findPreviousLine() -- once I work out the solution to bug 506360, that should also speed up. Thanks!
Just out of curiosity, I ran the profiler with and without the patch to this bug and tabbed through the advanced search form in bugzilla. Seems to double our speed. Here's Gecko.locusOfFocusChanged(): ncalls tottime percall cumtime percall 58 0.006 0.000 25.903 0.447 not patched 58 0.005 0.000 11.502 0.198 patched
More interesting test: I navigated to the top of bugzilla's advanced search form and pressed H for next heading (knowing full well there are no headings so that Orca would have to search from the top to the end of an admittedly full page). Without the patch: 1,015,996 function calls (1,015,866 primitive calls) in 128.807 CPU seconds (Thousands separator added for dramatic effect. Yes, over 1 million calls.) With the patch: 194,041 function calls (193,904 primitive calls) in 14.467 CPU seconds 10 times fewer calls! Although once I get find{Next,Previous}Line() sorted out, I bet I can do even better. Regardless.... goNextHeading() comparison: ncalls tottime percall cumtime percall 1 0.000 0.000 119.780 119.780 no patch 1 0.000 0.000 5.120 5.120 patch :-) :-) :-)
Created attachment 101923 [details] [review] fix "popping out of lists" issue Mike pointed out that we were sometimes "popping out" of focusable HTML lists. That's independent of this bug, but might as well get it here. Mike please test.
We are now not popping out of list. thanks much
I was just chatting with Mike. We agreed to go ahead and commit the patch as it seems sound (works, pylinted, regression tested) and helps performance. Leaving the status as "testing required" because it should get hammered on more to be sure.
I'm going to mark this as pending since we've defined 'testing required' as 'a patch has been attached to the bug but will not be committed until others have confirmed its validity'. No worries, though. We can leave this as pending until others have had a chance to beat on it. Thanks!
Closing as FIXED as per team meeting. We will open a new bug to address combo box issues.