Bug 4185 - Quick search does not release focus on 'Enter'
Summary: Quick search does not release focus on 'Enter'
Status: RESOLVED INVALID
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: QuickSearch (show other bugs)
Version: 3.17.4
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2019-03-24 11:42 CET by George
Modified: 2019-03-25 10:25 CET (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description George 2019-03-24 11:42:18 CET
STR:

1. Press '/' to set focus quick search
2. Type something to search for
3. Press enter
4. Press Shift+N to go to next unread message

EXPECTED:

Next unread message should be selected

ACTUAL:

The cursor remains in the quick search field and the result of "Shift+N" results in adding an 'N' to the search string. Only clicking with the mouse outside of it releases the focus.

3.17.3git142
Comment 1 Michael Rasmussen 2019-03-24 12:03:12 CET
(In reply to comment #0)
> 
> The cursor remains in the quick search field and the result of "Shift+N"
> results in adding an 'N' to the search string. Only clicking with the mouse
> outside of it releases the focus.
> 
If claws showed the behaviour you expect how would you then enter a search string with the letter 'N'?
Comment 2 George 2019-03-24 12:09:07 CET
> If claws showed the behaviour you expect how would you then enter a search string with the letter 'N'?

The same way it is done in any other input field (e.g. browser search field, address bar, email subject field, etc), i.e. by:

- clicking in the search filed again
- by using '/' again
Comment 3 Paul 2019-03-24 12:38:21 CET
just use TAB or SHIFT+TAB to move the focus to where you want it to be.
Comment 4 George 2019-03-24 13:51:21 CET
> just use TAB or SHIFT+TAB to move the focus to where you want it to be.

That's not what is expected from an input field. The general expectation (think usability) is to release focus after pressing "Enter" so that other shortcut keys can work. At least this is how other software works.

Not sure why you are marking this as "invalid".
Comment 5 Paul 2019-03-24 13:56:26 CET
(In reply to comment #4)
> > just use TAB or SHIFT+TAB to move the focus to where you want it to be.
> 
> That's not what is expected from an input field. The general expectation
> (think usability) is to release focus after pressing "Enter" so that other
> shortcut keys can work. At least this is how other software works.
> 
> Not sure why you are marking this as "invalid".

'Release' the focus to where?

It's invalid because it was designed to work in the way it does.
Comment 6 George 2019-03-24 19:02:19 CET
> 'Release' the focus to where?

To where it was before step 1.

> It's invalid because it was designed to work in the way it does.

Why is it designed to work this way, considering that no other UI works like this? It is inconvenient to have to press additional key (combination). What is the premise to expect to be able to keep typing after pressing 'Enter'? Usually 'Enter' means "now do it", not "I have more instructions".
Comment 7 Paul 2019-03-24 20:36:03 CET
You suggest that capital (upper case) letters should be disallowed in the QuickSearch text entry box?
Comment 8 George 2019-03-24 20:48:59 CET
No.

I suggest that hitting 'Enter' releases the focus from quick search, so that other shortcut keys work as expected (which is the normal behavior in user interfaces accepting text input).
Comment 9 Paul 2019-03-24 23:56:26 CET
They do, apart from hot key combos using the shift key and a letter, as these are used for upper case letters and you're in a text widget. Try for example a hot key combo that is ALT+[KEY].
Comment 10 Andreas 2019-03-25 09:18:00 CET
The behavior described in the original post would be new then. Is it something that has been implemented in the git version, to keep focus on the search input?
I'm currently using the 3.17.3 release, and when I'm searching for something and hit Enter, the focus moves to the message list, and I can use Shift+N as expected.
The only case, where the search input keeps focus, is in case the search result delivers 0 matches, i.e. there is no message to focus in the message list.

I must agree with George, that after you hit the Enter button, you usually expect to navigate through the search results, and not the search term. The comments mentioning that capital letters wouldn't work anymore are a bit of an overreaction, because it explicitly states that the shortcuts should work only after hitting the enter button, not while typing the search term.
Comment 11 Paul 2019-03-25 10:25:44 CET
(In reply to comment #10)
> The behavior described in the original post would be new then. Is it
> something that has been implemented in the git version, to keep focus on the
> search input?

That would be the fix for bug 2131.