128500 - quicksearch: string becomes highlighted during a pause in typing

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P1)

Description

[sairuh (rarely reading bugmail)]

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!]

Comment 1

[jglick]

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

Comment 2

[Navin Gupta]

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.

Comment 3

[scottputterman]

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).

Comment 4

[sairuh (rarely reading bugmail)]

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

Comment 5

[jglick]

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.

Comment 6

[Navin Gupta]

Attachment: proposed fix

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.

Comment 7

[Navin Gupta]

Attachment: proposed fix

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.

Comment 8

[Navin Gupta]

Attachment: patch as per mscott's comments

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

Comment 9

[Navin Gupta]

Comment on attachment 72685 [details] [diff] [review]
proposed fix

seth,
this is the right patch.

sorry attached patch from 
another bug.

Comment 10

[timeless]

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.

Comment 11

[(not reading, please use [e-mail] instead)]

taking.  I'll review / drive this one.

Comment 12

[(not reading, please use [e-mail] instead)]

Comment on attachment 72685 [details] [diff] [review]
proposed fix

sr=sspitzer

I reviewed and tested this patch.

Comment 13

[(not reading, please use [e-mail] instead)]

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

Comment 14

[David :Bienvenu]

Comment on attachment 72685 [details] [diff] [review]
proposed fix

r=bienvenu, if you add a comment that 13 is Enter/CR.

Comment 15

[(not reading, please use [e-mail] instead)]

> if you add a comment that 13 is Enter/CR.

will do before I check in for naving.

Comment 16

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 72685 [details] [diff] [review]
proposed fix

a=shaver for 1.0 trunk.

Comment 17

[(not reading, please use [e-mail] instead)]

fixed.

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

Comment 18

[laurel]

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.