It's so laggy you don't get feedback as you type, so you think it's not responding, so the odds of typos, or of restarting from / or ', go way up. What can be done? I hear it's fast (enough) on Windows. /be

Once up, it's fast enough -- the problem is when you have no Find toolbar and you type / or ' (or ctrl-F, I suppose). Hope this isn't a DUP, Asa said to file it. /be

bug 253773 might be one factor

Making a dependency for now -- if there's no specific Linux problem, this bug can be dup'ed. /be

Anyone (reporter? =) ) have a profile?

yeah, lets get a test case. who wants to help diagnose?

searching for anything in the bug seems fine on my windows laptop... what page are you looking at.

chofmann: first, this may be Linux only, so testing Windows won't help, although bug 253773 is cross-platform. So second, try loading up other tabs with real pages that take time to reflow. /be

dbaron, can you try and profile this and come up with some options on how it can be fixed?

bryner has patches that might help this, but is concerned they may break things. He demo'ed them and they do speed it up markedly, but dbaron et al. should look over them.

I have a patch waiting for review on bug 227361. The things bryner was discussing yesterday on IRC sounded quite scary.

Oh good, there's a bug about this. I'd always assumed it was just my crappy PC and was of acceptable speed for everyone else. Yeah, find-as-you-type, ever since toolbar implementation, has been a fairly crummy experience on Linux. I have noticed one thing, however, that may help diagnose a cause of this. Steps: 0) restart Firefox, to ensure you're in the normal state (I think the state for this bug really depends on what you last searched for, and if it was found). 1) load a page, and hit / to open the search bar 2) type "test", or anything, to do a bogus search. 3) when it says "Phrase not found", hit Escape to close the toolbar 4) hit /, to open the search bar again Now here's the weird thing. This second time that you open the toolbar, there is a clear delay between when the toolbar draws, and when the icons for the three buttons draw. So first you see: [__________________] Find Next Find Previous Highlight Phrase not found Just like that. No color, no icons. Then, after a consistent, approximately one second pause (during which you can't type), the icons are added to the display. And the even weirder thing is all of the buttons are enabled, despite the text field being blank. So you can do a "Find Next" on that null string, which errors with "Phrase not found", and turns the text box that orangeish-red. (in step one, when the search bar is first brought up on the page, those buttons are disabled). During the "consistent" pause, CPU use does not mac out at all though, unlike other UI hangs where it's mearly a XUL bottleneck. In this case, it basically looks as if the code just does sleep(1)!

(Specifically, the patch I have is for speed opening/closing, and fixes bug 253773. This bug covered many issues from the start and now seems to cover even more.)

If dbaron's fix at bug 227361 is all we're going to get here, then can we pull this off the blocking list? (this question is directed at the bug owner, drivers or the aviary team.)

ok, sounds like it is time to move this one off the list. brendan comment on speed if there are still significant problems

*** Bug 264962 has been marked as a duplicate of this bug. ***

seems plenty fast to me on Linux, if there's still problems, nominate for b4 or forever hold your peace.

Marking this as WORKSFORME after discussing with Wayne Mery on IRC.