what i'm seeing might be due to the fix in bug 114960, but i find it a bit confusing. if i pause while typing in the quicksearch field in the mail 3pane window, the string becomes highlighted. if i resume typing, whatever i enter overwrites what i had there previously --not good esp since i did not intend to erase what i had there, i had wanted to *add* chars to it. i could understand some of the logic, though: during that pause, the search is occurring, and then string becomes highlighted once the search has completed. however, highlighting the string would prolly be better if it were limited to only (1) hitting the enter/return key and (2) mouse-clicking into the qs field itself. [side note: in the browser urlbar, click to select is the expected behavior, at least on win32 and mac. on linux, clicking just places the cursor. i know, i know, i've been a pest about maintaining the default linux behavior in the past. ;) i confess i could adapt to the win32/mac behavior. ;) as it stands, there is at least a backend pref to toggle it, which i think is a nice option, personally. okay, end of silly digression!]

Or maybe just delaying the time between when the user stops typing and the contents get selected...

The contents get selected once the search is started/issued. so if you stop typing the timer fires, search starts and contents get selected. We could increase the delay- highlighting the search text after search is over.

I haven't tried this yet so I'm making this comments and keyword markings just from reading the bug. It would seem to me that we shouldn't select when a search is issued unless they hit return because that most likely means they are done. If I'm just typing and the search is happening from autocomplete, I don't think you can know that the user is done and it will be easy to end up in the situation mentioned in this bug. I'd say, select the text when: 1. The user hits return when typing 2. The user returns focus to quicksearch (like the url bar does).

i agree with what scott suggests in comment 3, which sound like more reasonable behaviors.

I agree as well. Highlight text when: 1.The user hits return when typing 2.The user returns focus to quicksearch (like the url bar does). We make both users happy this way, the ones who want the text to highlight and those that don't.

OnInput() handler does not get called when you press return key. I think it is a special type of handler that gets invoked only when it receives "real" input. So the fix is to add onkeypress handles and check if the user has pressed return key. yes, the return key was not working for QS and it will start working now! please review.

OnInput() handler does not get called when you press return key. I think it is a special type of handler that gets invoked only when it receives "real" input. Also I found out that event.keyCode always returns 0 in onInput(). So the fix is to add onkeypress handler and check if the user has pressed return key. yes, the return key was not working for QS and it will start working now! please review.

Made it to use wstring PRUnichar ** native types, I don't know why I left it as nsString, nice catch.

Comment on attachment 72685 [details] [diff] [review] proposed fix seth, this is the right patch. sorry attached patch from another bug.

i can't tell from here, but please be sure to honor the clickselectsall pref. personally after having used quick search on my laptop, i will disable click selects all, and i will expect that the only time this thing ever highlights is if i use ctrl-a or shift-home. there's really no need to ever select this field, there's a clear button, and you're using it to progressively search.

taking. I'll review / drive this one.

Comment on attachment 72685 [details] [diff] [review] proposed fix sr=sspitzer I reviewed and tested this patch.

re-assigning back to naving, it's his fix.

Comment on attachment 72685 [details] [diff] [review] proposed fix r=bienvenu, if you add a comment that 13 is Enter/CR.

> if you add a comment that 13 is Enter/CR. will do before I check in for naving.

Comment on attachment 72685 [details] [diff] [review] proposed fix a=shaver for 1.0 trunk.

fixed. note to naving, when you update, you'll have conflicts.

OK using mar19 commercial trunk build: win98, linux rh6.2, mac OS 9.2 Doesn't highlight search text unless Enter pressed. Highlights on user (re)focus in text field with existing text.