Search Messages box does not allow to search in message body

This is entirely intentional; we even have mozmill tests that make sure this happens.

I could see having a bug filed on our presentation of this intent in the menus, of course...

I'm confused - these are two entirely different things, aren't they?

They are both searchy things using the keyboard, and find-in-message can be directly triggered by control-g or what not if so desired.

I see your point, I figured though that it's confusing for the user if the same shortcut triggers different actions based on subtle differences in the current status.

Thinking more about it, Ctrl+F is also the Find in This Page shortcut for Firefox, thus keeping it for Find in This Message would be consistent. The question would be then which other shortcut is available for Quick Filter. Shift+Ctrl+F is already occupied by the full message search, Shift+F maybe? Either way, changing it would also require to modify the message shown in the inactive state (referring to Ctrl+F), and it's past the string freeze...

overloading of this key is confusing for me also, and suspect it must be worse for the average user - me being less than average :)

ctrl+Q ?

I'm pretty sure that's the quit key on linux...

Yes, Ctrl+Q was only removed on Windows platforms (was my first idea too).

It is actually possible to get into a state where Ctrl+F doesn't do anything. If you are in a folder without any message currently shown, Ctrl+F will only work once for the quick-filter bar, any subsequent keyboard shortcut isn't effective. My guess is that "Find in Message" grabs the focus and won't release it any more as for some reason it does when a message is selected.

Is "/" used by anything? It's the "Quick Find" in Firefox, so maybe that's a good enough precedent?

Actually, "/" opens the "Quick Find" bar in Thunderbird as well, it disappears after a while and doesn't have the options the full "Find in This Message" bar has. I agree that it would have been a good alternative shortcut.

How about Ctrl+"/" for the within-message search bar? This would be somewhat different from Firefox but seems to be consistent:

            "/" - Find as you type (Quick Find)
       Ctrl+"/" - Find in this message
       Ctrl+"F" - Quick-Filter search
 Shift+Ctrl+"F" - Full Search Messages dialog

(In reply to comment #11)
> How about Ctrl+"/" for the within-message search bar? This would be somewhat
> different from Firefox but seems to be consistent:
>
> "/" - Find as you type (Quick Find)
> Ctrl+"/" - Find in this message
> Ctrl+"F" - Quick-Filter search
> Shift+Ctrl+"F" - Full Search Messages dialog

Bryan thoughts ?

Maybe it will be better to make Ctrl+F contex-sensitive?
While message body is focused, show finbar in message view.
While messages tree or accounts tree are focused use Quick Filter.

I think that's actually what it's doing right now, but the focus apparently alternates between elements, thus there is no clear context.

No, right now it work in very strange way, at least in TB 3.3b2.

steps:
1) Click in message view, to make it focused. Now if You use arrows, You can scroll message.

2) use Ctrl + F:
  result: Quick Filter shows, and its textbox become focused.
  expected result: message view findbar should be shown.

3) use Ctrl + F again (while Quick Filter textbox is focused)
  result: findbar in message view appear.

I think it should work this way:
1) if message view is focused, Ctrl + F should invoke findbar in message view. Also other shortcuts should work for finbar (like F3 "find next"). Subsequent Ctrl + F should not move focus to Quick Filter.

2) if headers tree is focused, or if accounts tree is focused, then Ctrl + F should open Quick Filter, and make it focused. Subsequent Ctrl + F should not move focus to Findbar.

3) I do not know which search feature should be used, if used use Ctrl + F when any other element is focused.
Probably Quick Filter should be dafault. In this case, context-sensitivity may be limited to message view. Only if message vie is focused TB use Findbar, otherwise Quick Filter will be used.

Note: Quick-Filter textboc cuebanner (gray text) should be adjusted as well when focus changes. Whilst headers tree or accounts tree are focused, it should contain "<Ctrl + F>" shortcut hint, but while message view is focused it should not contain shortcut hint.

(In reply to comment #8)
> If you are in a folder without any message currently shown, Ctrl+F will only
> work once for the quick-filter bar, any subsequent keyboard shortcut isn't

Interesting, the logic for the focus seems to be reversed here. Without any message selected, Ctrl+F initially opens the Quick-Filter bar. I'm clicking ESC to close it, then Ctrl+F won't do anything. If I click into the (empty) message preview pane to focus on it, Ctrl+F will open and focus the Quick-Filter bar after that again (TB 3.1 RC1 build3, WinXP).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100526 Lightning/1.0b2 Thunderbird/3.1

rsx11m, how do you get into the state of "no message selected" (empty message preview pane)? I also once saw the problem mentioned in comment 8, but unable to reproduce. rsx11m, can you?

(In reply to comment #16)
> Interesting, the logic for the focus seems to be reversed here.

Reversing or ignoring focus logic is one of Bryan's favourite pastimes ;)
(Make a backup of your profile(!), place focus on attachment, press ctrl+a, [do the backup now or you're up for dataloss!!], then shift+del to see what I mean - bug 315144, bug 281046).

Jokes aside, there's 2 competing concepts here:
1) give priority to focus (change the actions associated with keyboard shortcuts based on current focus)
2) give priority to keyboard shortcuts (always do the same action associated with a given keyboard shortcut, regardless of focus - like a master key)

I'm inclined to think that 1) should have priority (especially when it comes to dataloss dangers), but probably both concepts have their benefits.

I'd think "Ctrl+F toggle magic" is an extreme variant of 2), where we assign two actions to the same shortcut (for good reason), while deliberately ignoring focus. I have been cracking my head if it feels right or not - I don't know. The benefit of ignoring focus is that unless focus happens to be in one of the search bar's already, you can always rely on the fact that the first Ctrl+F will take you to quickfilter bar. The irony being that you still need to check your focus, because if it's already in the quickfilter bar, you'll lose it if you just press Ctrl+F again. On the other hand, I'm sure I'd be a lot happier if, when focus is on the message text, Ctrl+F would search my message text immediately.

Until today I thought that Ctrl+G would help me out for reliable message text search - but it stops working if you press it more then once in a row (text not found), and strangely enough, it sets the cursor into the message and won't go back to the text search ever after.

Please note that Ctrl+/ is a three-key-shortcut on some non-English keyboards (e.g. on German keyboard, we'd have to press Ctrl+Shift+7 to get Ctrl+/). Therefore, I'd rather not have that as the main shortcut for search in message, but I don't mind having it as an additional shortcut. Ctrl+G as we have now should be alright, but I'm not sure that it behaves exactly the same as Ctrl+F used to.

(In reply to comment #17)
> rsx11m, how do you get into the state of "no message selected"

You may need to disable mailnews.remember_selected_message (which I have in all my installs). When you enter a folder, it won't have the last picked message selected by default but simply show the message list.

Comment #8 is valid until you click into the empty message, so that's related to the follow-up comment #16.

> I'm inclined to think that 1) should have priority (especially when it comes to
> dataloss dangers), but probably both concepts have their benefits.

Your Ctrl+A example would rather suggest that different shortcuts are to be preferred rather than relying on the focus, to avoid ambiguities. On the other hand, I see the issue that it's easy to run out of keyboard buttons in this way and end up with non-intuitive ones ('A'=all and 'F'=find, makes sense).

> Please note that Ctrl+/ is a three-key-shortcut on some non-English keyboards

Good point... I was trying to avoid l10n issues (post-freeze) by suggesting that combination, but apparently it's still an internationalization problem.

(In reply to comment 8, comment 16, comment 18)
followup for the problem described by rsx11m:

Bug 571280 - Ctrl+F does nothing after ESCaping quickfilterbar, if no msg selected for preview (or mailnews.remember_selected_message = false)

Thanks. Due to the string freeze in effect for the 3.1 branch, it's probably more advised to concentrate on the focus issues (here and/or there) anyway,
thus the context of the keyboard shortcut is clear to the user w/o confusion.

Personally I don't see any reason for the confusion caused by sharing the key combo...

How about Alt-F for one and Ctrl-F for the other? Or Ctrl-Alt-F if Alt-F is used by another OS (it doesn't seem to be assigned in Windows)?

I think the Alt key is only used for accessibility of the menus (i.e., the underlined character in menus and dialog boxes indicates which action is performed when hitting Alt+that key), I don't know about Ctrl+Alt.

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

(In reply to comment #3)
> They are both searchy things using the keyboard, and find-in-message can be
> directly triggered by control-g or what not if so desired.

I'm confused...

What is the point of having two different keyboard shortcuts - in this case ctrl-g and ctrl-f - that do the same thing?

I'd much prefer to see ctrl-g made a TOGGLE to quickly toggle the 'find in message' toolbar, and ctrl-f to TOGGLE the Quickfilter toolbar. Having combined functionality is just asking for complaints, even from advanced users (as evidenced by this bug and the comments in it).

Ctrl+F is opening the Find in Message dialog and allows you to enter a search term. Once you closed it, Ctrl+G searches for the same term without reopening
the in-message search bar. Ctrl+G will only behave like Ctrl+F the first time
if nothing has been searched for yet. Thus, comment #3 is not quite accurate.

(In reply to comment #25)
> Ctrl+F is opening the Find in Message dialog and allows you to enter a search
> term.

Hmm.. did this change in 3.1? I know for a fact that at some point in 3.x, CTRL-F brought up the Quickfilter Toolbar, but I can't make it do it now...

Wait... I think I changed this using keyconfig because it was so irritating... yeah, I set CTRL-ALT-F to bring up the QF toolbar, so now CTRL-F only brings up the 'find in message' toolbar, and ESC toggles each off.

> Once you closed it, Ctrl+G searches for the same term without reopening
> the in-message search bar. Ctrl+G will only behave like Ctrl+F the first time
> if nothing has been searched for yet. Thus, comment #3 is not quite accurate.

Ok, well, whatever the case may be, it is totally confusing and very user unfriendly. No worries though, the way I have it configged right now works well for me, unless/until the 'standalone quickfilter widget' is every implemented (crosses fingers)...

From a Mac user's perspective, NOT having "Cmd-F" be "Find" and "Cmd-G" be "Find Again" is not in keeping with the expected "look and feel"; I suspect this is true for other OS's, as well. It's also not in keeping with the previous "point release" of TB, where "Cmd-F" was "Find in Message..." (disabled if no message tab/window open -- at least in my case, with the Message Pane not displayed), and "Shift-Cmd-F" was "Search Messages..." (or some "modifier-Cmd-F").

As an aside (and what should be the subject of another bug): It's not intuitively obvious how to CLOSE the "Quick Filter Bar" if one -- who is used to using "Cmd-F" -- happens to cause the bar to appear by pressing "Cmd-F" (i.e., no "close" button on the bar).

Personally I've always thought of CTRL+F as being there to forward a message, and this seems to be the default in most mail clients. Why can't CTRL+K be used for search, like in Firefox?

(In reply to comment #28)
> Personally I've always thought of CTRL+F as being there to forward a message,

Strange thought, have you ever actually tried that since TB 2.0 (or perhaps even before that)? Press Ctrl+F in FF and many other apps and know why Ctrl+F for "Find" makes a lot of sense. Until 3.1, we've had Ctrl+F for "Find in message text".

> and this seems to be the default in most mail clients.

Could you list these? What shortcuts do they use then for "Filter", "Find messages", "Find text in message"?

> Why can't CTRL+K be used for search, like in Firefox?

Just press ctrl+k in TB and you'll know why. If your next question is "but why can't we have a combined search box for filters & global search?", then that's a legitimate question that's covered by other bugs, like bug 526221, or bug 570815.

CTRL+F to Forward a message is default in:

- Outlook (probably one of the most used mail clients, certainly in the business world)
- Evolution
- Windows Live Mail (interestingly, they use CTRL+Shift+F to Find, and CTRL+F to forward, which seems like quite a good idea)
- The Bat!
- Mutt (F key)
- Pine (F key)

I don't think CTRL+L is a good shortcut for forwarding. I think CTRL+Shift+F should be used to Find, and CTRL+F to forward.

Regarding the second point, I agree having two search boxes is actually a good idea (I always thought combining the two was confusing). So shortcuts should be:

Global search - CTRL+K (as currently is)
Filter search - CTRL+Shift+F
Forward message - CTRL + F

(In reply to comment 30 and comment 31)
Maxozilla, thanks for adding details. Please test any shortcuts that you propose to change, to see if and for what they are currently in use. Comment 31 doesn't consider that Ctrl+Shift+F is currently taken for advanced "Edit > Find > Search messages". We also need to keep in mind the main problem of this bug, which is the current double function of Ctrl+F used for "Quick Filter" and "Edit > Find > Find in this message" (again, the latter not covered in comment 31). Maybe proposing a new shortcut for "Forward" is OT and needs a separate bug.

Do not change keyboard shortcuts, please... it always take months to get used to new ones.

For Thunderbird we should no care about shortcuts in other mail programs. Rather we should preserve existing shortcuts as long as possible.

But if You really want to take other programs into account, then consider fact that many programs use CTRL+F for "find" function.
For me CTRL+F >> "find" is most natural.

One problem is fact, that pressing CTRL+F while message pane is focused, opens find function in tree, instead of find function in message.
I think CTRL+F should be contextual, in message pane it should open message pane findbar, otherwise it should open QuickFind.

I would propose:

Filter Search - / (like Firefox Quick Search)
Global Search - Ctrl+K
Advanced search window - CTRL+Shift+F
Forward Message - Ctrl+F
(just as Ctrl+R is for Replying to a message)

I agree a new Forward shortcut is a separate issue, but it can impact the
decision made in this bug.

(In reply to comment #33 and comment #34):

Comment #33 sums up my opinions quite succinctly:
1) Don't change just to change -- consistency will "endear" users.
2) Consider ALL other applications on any specific platform, not just
   mail applications. Hot keys DO differ between platforms, but
   usage on the platform should be consistent.
3) Contextual is OK, allows "overloading", and makes sense (how
   can you search in message when there's no message selected?).

Changing HotKey for Forward Message -- see #1, above.

Now is the time to revert "Find in message" from CTRL-G back to CTRL-F, before too many users are confused by it as they upgrade to later versions of TB; too bad it couldn't have happened at 3.1.2.

All, please stay on topic in this bug - if you think that the forward shortcut should be changed, please open this as your separate bug. This is on searching.

The task here is actually twofold:

(1) Untangle cmd_find, which is used for Ctrl+F and Edit > Find > Find in this Message and toggles either the Quick Filter Bar or Find in Message; meaning, the Quick Filter Bar needs its own command cmd_qfbOpen or similar, which would solve the issue described in bug 581566 along with the focus issue.

(2) Define a new shortcut for the new Quick Filter Bar, then associate it with the new command created in step (1). It appears Ctrl+B (=bar) isn't used yet?

[There is also a step (3), update the tests for the qfb-toggling behavior.]

(In reply to comment #35)
> Now is the time to revert "Find in message" from CTRL-G back to CTRL-F, before
> too many users are confused by it as they upgrade to later versions of TB; too
> bad it couldn't have happened at 3.1.2.

The Ctrl+G shortcut for "Find Again" actually never changed, only the menu label has been rewired to present it also as "Find in This Message" shortcut. This is pending review for the patch in bug 575018 and should be an easy fix.

(In reply to comment #36)
> (1) Untangle cmd_find [...]

Ctrl-F still does do "Find in Message" when a message is open -- Bug 575018 will change the menu "key equivalent" back to Ctrl-F (if I read your comment there correctly).

> (2) Define a new shortcut for the new Quick Filter Bar, then associate it with
> the new command created in step (1). It appears Ctrl+B (=bar) isn't used yet?

I'm beginning to wonder why QFB even needs a keyboard equivalent, since it's "sticky"; it's the only "Toolbar" menu selection that has a key equivalent (or at least, the only one that has one listed in the menu).

> [There is also a step (3), update the tests for the qfb-toggling behavior.]

If qfb has it's own key, then its "co-opting" of Ctrl-F should be eliminated and the tests updated. If the co-opting is not eliminated, then there's no need for qfb to have its own key and no need to update the tests (unless there weren't any to begin with).

(In reply to comment #37)
> Ctrl-F still does do "Find in Message" when a message is open -- Bug 575018
> will change the menu "key equivalent" back to Ctrl-F

Yes, it swaps key_findAgain against key_find to match the cmd_find that menu option actually performs. It's only correcting that shortcut label.

> I'm beginning to wonder why QFB even needs a keyboard equivalent, since it's
> "sticky"; it's the only "Toolbar" menu selection that has a key equivalent (or
> at least, the only one that has one listed in the menu).

It is possible to hide the QFB (and even to hide its handle in the tab bar as well if mail.tabs.autoHide is set) by just hitting the ESC key twice. So, the keyboard shortcut provides a quick way to open and focus into it, thus I'd say that it's worth retaining and just separating it from Ctrl+F.

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