updating autocomplete search engine text is slow



Location Bar
17 years ago
10 years ago


(Reporter: janne hayrynen, Assigned: Joe Hewitt (gone))



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nav+perf])


(1 attachment)



17 years ago
linux 2001050308

when i type an url to location bar, a line appears under it with the text
"search <some search engine> for <the url you are typing>".
well, that is just fine and dandy, but even when typing at a "normal" speed,
this automatically updating and resizing search-bar thingie seems to hog all the
cpu in the world and can't keep up to my typing on a 600mhz machine.

and more to the point, what is this search-bar-thing needed for anyway? there is
already a "search" button right of the location bar that does exactly the same
thing, so what good does this little eye-candy do? and seems like there is no
way of getting rid of it either, turning the search-button off from preferences
doesn't get me rid of this "search netscape search for qwer..." line.

*me very cranky*

Comment 1

17 years ago
that's not search, that's url bar. and how do you know what's eating the cpu?
Assignee: matt → alecf
Component: Search → URL Bar
Keywords: perf

Comment 2

17 years ago
yes, you're right, i haven't really done any digging on this so it's mostly

but anyhow, as an average user the only difference i can see to a build few days
ago is the search-thing. before that came along, typing to url bar hardly caused
any noticeable cpu usage, now cpu usage leaps to 100% and it can't keep up.

so it might or might not be the cause, just my observation.. :)

Comment 3

17 years ago
I guess this should be on a timer.. hewitt?

Comment 4

17 years ago
Assignee: alecf → hewitt
Summary: the "search <somesearchengine> for" -line hogs cpu, makes typing an url slow and is redundant & irritating in every way i can think of. → updating autocomplete search engine text is slow

Comment 5

17 years ago
Ever confirmed: true

Comment 6

17 years ago
This has been affecting me as well, since hewitt's landing. Typing a url in is
definitely too slow. It is unfortunately not easily measurable, but characters
do 'lag' some way behind my typing. It is also very noticable when you have the
caret at the end of a longish url, and hold down the delete key - takes some
time to blank the field.

Comment 7

17 years ago
The search should not append and the dialog should not appear unless the typing
speed is less than X. Like the time between two keystrokes is less than X...
Would not be hard to implement, wasn't like that before?, and it would make a
huge speed improvement to enter text. Autocomplete is just unusable here...

Comment 8

17 years ago
It turns out that typing speed doesn't change that much with autocomplete turned
off. With it switched off, it's still unacceptably slow. See bug 83205, ccing
hyatt from there.


17 years ago
Whiteboard: [nav+perf]

Comment 9

17 years ago
Created attachment 41137 [details] [diff] [review]
patch using a timeout to update search text

Comment 10

17 years ago
My computer is too fast (and is win2k) to notice the slowdown anyway - can
somebody experiencing the pain please try out the patch I just posted and let us
know if it improves performance?

Comment 11

17 years ago
just landed patch that should speed this up.  I hope it helps.  Marking fixed,
but if people feel that even with this patch it is still slow, reopen.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 12

17 years ago
The problem has disappeared here on 0.9.4. There is also a nice pref to disable
this behavior, so I guess it is safe to mark this as verified.

Comment 13

17 years ago
I think this should be reopend... (regression?)

On my PII-266MHz/256MB/Linux 2.4.4/Gnome1.4/Sawfish with build 2001112308 typing
in the locationbar is slow unless I turn autocomplete off..

This happens since a couple of days ago (as far as I can remember). Have not
checked with previous builds. Will do that tomorrow.

Comment 14

17 years ago
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.