Closed Bug 564328 Opened 14 years ago Closed 13 years ago

Keyboard shortcut Ctrl+F conflict and cmd_find ambiguity, used for both Find in This Message and Quick Filter (now Ctrl+Shift+K for QFB)

Categories

(Thunderbird :: Search, defect)

Product:
Thunderbird
Component:
Search
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-thunderbird5.0 -)

Status:
VERIFIED FIXED
Milestone:
Thunderbird 8.0
Tracking Flags:
Tracking Status
blocking-thunderbird5.0 --- -

People

(Reporter: rsx11m.pub, Assigned: squib)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: ux-userfeedback, Whiteboard: [gs][UXPrio][affects l10n])

Attachments

(4 files, 4 obsolete files)

Show FindToolbar if message pane gets focus.
2.29 KB, patch
standard8
: ui-review-
Details | Diff | Splinter Review
menu wrongly describes what first invoking of Ctrl+F does
125.46 KB, image/png
Details
Patch for checkin
8.85 KB, patch
squib
: review+
Details | Diff | Splinter Review
Fix strings
1.83 KB, patch
bwinton
: review+
Details | Diff | Splinter Review 
(From bug 562694 comment #2)
> Re Ctrl+F: I think that I've seen a bug pending somewhere on this already, but
> that keyboard shortcut actually has two functions: If a message is currently
> viewed in the message viewer, Ctrl+F opens alternatively the quick-search or
> the find-in-message bar, which is quite confusing. Let me know if it's not yet
> filed (can't find it again right now) and I can open another bug for this.

Steps to reproduce:
1. Select any message in Inbox or other folder;
2. repeatedly use the Ctrl+F shortcut, close with ESC;
3. watch alternatively Find in Message or Quick Filter getting focus.

Observed first in TB 3.1 beta 2 build 1 on Windows XP.
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.
Keywords: ux-feedback
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)
Depends on: 571280
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.
(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.
URL: http://gsfn.us/t/19356
Whiteboard: [gs]
Blocks: 605545
Can we aim for a solution targeting 3.2 here? Just to summarize:
- actual behavior of Ctrl+F shortcut depends on focus and appears arbitrary;
- with a specific focus, the Ctrl+F shortcut isn't doing anything at all;
- the behavior of the "Find in Message" menu is tied to the command and thus
  it's equally unpredictable which action it performs.
blocking-thunderbird3.2: --- → ?
Summary: Keyboard shortcut Ctrl+F conflict, used for both Find in This Message and Quick Filter → Keyboard shortcut Ctrl+F conflict and cmd_find ambiguity, used for both Find in This Message and Quick Filter
Since there has been some confusion in bug 608149 what the issue to be handled here is about, let me expand on comment #40:

 1. Both Ctrl+F and Edit > Find > Find in This Message are tied to the same
    cmd_find in the backend, which has the ambiguity with View > Toolbars >
    Quick-Filter Bar (hence marking the menu-related bugs as duplicates).

 2. Solving this bug implies three issues to be taken care of simultaneously:
    - separate quick-filter bar from cmd_find
    - fix menu associations with the respective new cmd_*
    - fix keyboard shortcuts for the respective menu items

I hope this explains it satisfactorily, and why it seems that handling these three issues at the same time in the same bug should be the way to proceed (i.e., one cannot be solved without the other two).
There is no ambiguity for me. ^F have always been the shortcut to search inside a text editor, since MS-Word97, Gaim, Gedit, Firefox in pages, TB in both editor and viewer. In my TB, Edit>Find menu clearly states that the "search message" should be SHIFT+^F.

The ambiguity is in the search bar itself, that writes <Ctrl+F>. When the feature have been designed, and integrated, the menus intuitively stated that search in messages are "shifted".

The bug is not about having two feature behaving on the same keystroke, but on have the new one (search message) behave when an older feature's keystroke is hit (search IN message). Bug description is wrong. There is no conflict or ambiguity. There is a mistake in the new feature implementation (and the light grey description in the texte field).
Whatever, it doesn't change anything in the to-do list of comment #43.
(In reply to comment #43)
>  2. Solving this bug implies three issues to be taken care of simultaneously:
>     - separate quick-filter bar from cmd_find
>     - fix menu associations with the respective new cmd_*
>     - fix keyboard shortcuts for the respective menu items

Clarification - does this mean a new/totally different keyboard shortcut be assigned to the Quick Filter Bar (yes = good answer)?
Yes, this would be the consequence of separating the two functions, giving the quick-filter bar its own cmd_* internally (which you would associate with a new keyboard shortcut to be determined). In agreement with comment #45, I'd expect that Ctrl+F remains "Find in This Message" for reasons of consistency.
(In reply to comment #48)
> Yes, this would be the consequence of separating the two functions, giving the
> quick-filter bar its own cmd_* internally (which you would associate with a new
> keyboard shortcut to be determined).

Alternatively, we could also assign a new shortcut for "search in message" and keep Ctrl+F for the QFB.
Another alternative, after disentangling the backend cmd_whatever and respective menus, we could still have a solution that uses Ctrl+F for both commands IF (and probably only if) we respect focus. Ctrl+F, with focus on the message text, could search the msg text as is to be expected. Ctrl+F, with focus anywhere else (except on message text), brings up QFB. Without deep consideration, this actually looks like a possible solution to me, without wasting and forcing upon the user new keyboard shortcuts which are most likely not available or very complex/unintuitive.


> In agreement with comment #45, I'd expect
> that Ctrl+F remains "Find in This Message" for reasons of consistency.

fwiw, I am sure you have to *find the message* first (using QFB) before you can actually "Find text in this message". iow, we can safely assume that qfb will be used more frequently than "find text in this message". Consequently, the most intuitive and less complex shortcut should be granted to QFB, which for many users will be their most used search tool.
If we really need to different shortcuts (which is arguable as laid out further up in this comment), then I'd certainly want Ctrl+F to trigger QFB search and find another shortcut for "find in msg text". Unless you can provide another really intuitive two-letter shortcut for QFB, which I doubt.
> we can safely assume that qfb will be used more frequently than "find text in 
> this message". Consequently, the most intuitive and less complex shortcut 
> should be granted to QFB, which for many users will be their most used search 
> tool.

That is a poor assumption. I've noticed in the MozillaZine forums that how people search (or want to search) reminds me of religious wars about editors. There are also a lot of people who are overwhelmed by the changes, complexity and fragility in 3.1.*, the last thing they want is something else they're used to to change.
Keep in mind that Ctrl+F and Ctrl+G shortcuts are also used for "Find in Page (again)" in Gecko-based browsers, look at Firefox and SeaMonkey (the latter using Ctrl+F for "Find in This Message" as well). That was the inconsistency
I had primarily in mind as a reason for not associating Ctrl+F to the QFB.
(In reply to comment #50)
>> we can safely assume that qfb will be used more frequently than
>> "find text in this message". Consequently, the most intuitive and
>> less complex shortcut should be granted to QFB, which for many users
>> will be their most used search tool.

> That is a poor assumption.

I disagree... I've polled most of our users here, and every one says the same as me - we almost *never* use the 'Find in this message' function, and use the QFB *all the time* - so, say, 99.9% of the time when I search is looking for a particular message, not some text in one individual message. GRanted, there will be certain users that deal with a lot of very long text messages that may be using the 'Find in  this message' a lot, but I am very comfortable claiming that that is the exception rather than the rule.

This is in fact why I'd dearly love to see Thomas' v3 mockup of bug 570815 implemented... it would make all of this moot, as you'd be able to have the full functionality of the QFB available all the time on any toolbar you wanted.

> There are also a lot of people who are overwhelmed by the changes,
> complexity and fragility in 3.1.*, the last thing they want is
> something else they're used to to change.

That's just it - most people I know don't even know about the 'Find in this message', much less actually have a need for it.
(In reply to comment #52)
> This is in fact why I'd dearly love to see Thomas' v3 mockup of bug 570815
> implemented...

Me too, but again - please let's stay on topic. First things first.
(In reply to comment #52)
> (In reply to comment #50)
> >> we can safely assume that qfb will be used more frequently than
> >> "find text in this message". Consequently, the most intuitive and
> >> less complex shortcut should be granted to QFB, which for many users
> >> will be their most used search tool.
> 
> > That is a poor assumption.
> 
> I disagree... I've polled most of our users here, and every one says the same
> as me - we almost *never* use the 'Find in this message' function, and use the
> QFB *all the time* - so, say, 99.9% of the time when I search is looking for a
> particular message, not some text in one individual message. 

> > There are also a lot of people who are overwhelmed by the changes,
> > complexity and fragility in 3.1.*, the last thing they want is
> > something else they're used to to change.
> 
> That's just it - most people I know don't even know about the 'Find in this
> message', much less actually have a need for it.

'Find in this message' functionality is very old, well known, and intuitive... In most programs CTRL+F invoke some kind of "Find" function.

I do not know details how keyboard shortcuts are mapped to code, but I think CTRL+F should be made context-sensitive. 
If user has focus in messages list, then CTRL+F should invoke Quick Filter.
If user has focus in message, CTRL+F should invoke 'Find in this message' functionality.

By the way, in Composer CTRL+F also allow You to "find in this message". 
It will be curious, if in future version, when composer will be in tab, user press CTRL+F and Quick Filter will popup...
(In reply to comment #12)
> > 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 ?

Some quick notes, I'm sorry to do a drive by after so much discussion has gone by.

We aren't going to change the ctrl+f away from the QFB, it's the much more commonly associated find type compared to find in message.

I'm sorry but we cannot rely on focus to change the behavior of the keyboard shortcut, using focus for things like this always ends in tears.

I think we could move to ctrl/cmd + "/" for the find in message and stop the toggle between the two finds (ctrl/cmd + g would still work as well).  This is a fairly easy change to push through if this bug stays on topic of just that.

There could also be other shortcuts besides ctrl+f for find in message that make more sense if people have more ideas about that.
(In reply to comment #54)
> (In reply to comment #52)
>> That's just it - most people I know don't even know about the 'Find in this
>> message', much less actually have a need for it.

> 'Find in this message' functionality is very old, well known, and intuitive...
> In most programs CTRL+F invoke some kind of "Find" function.

For you maybe. Like I said, of the 50+ people here that I polled, only about 4 of them even knew it existed, and they said they *never* use it.

When I asked about the Quickfilter, every one of them said they use it *all the time*, dozens if not hundreds of times a day.

> I do not know details how keyboard shortcuts are mapped to code, but I think
> CTRL+F should be made context-sensitive. 
> If user has focus in messages list, then CTRL+F should invoke Quick Filter.
> If user has focus in message, CTRL+F should invoke 'Find in this message'
> functionality.

I'd be ok with that, since most people never click in the actual email body when reading a message, so in almost all cases, CTRL-F would toggle the QFB.
(In reply to comment #55)
> We aren't going to change the ctrl+f away from the QFB, it's the much more
> commonly associated find type compared to find in message.

Agreed - but the problem is it seems to almost always (for me) invoke the Find in this message rather than the QFB. That is why I went to so much trouble to find a workaround (install keyconfig, get help from the author on how to create a new shortcut to invoke the QFB (couldn't get toggle to work sadly).

> I'm sorry but we cannot rely on focus to change the behavior of the keyboard
> shortcut, using focus for things like this always ends in tears.

I agree, as this bug is clear evidence of.  only agreed with the suggestion because the conflict would almost never happen (at least for me).

> I think we could move to ctrl/cmd + "/" for the find in message and stop the
> toggle between the two finds (ctrl/cmd + g would still work as well).  This is
> a fairly easy change to push through if this bug stays on topic of just that.

+100! :)

> There could also be other shortcuts besides ctrl+f for find in message that
> make more sense if people have more ideas about that.

Since it is so rarely used (by myself and everyone I've asked), I'd be fine with a toolbar button (as well as a header pane button)...
I use Find In Message 3 - 4 times as often as QF.  Half of my mail is long chains that I have no interest in perusing word-for-word, or long articles with the same limited appeal. QF is fine for locating an old message for research purposes, but I rarely need that. Dropping the 'FIM' entirely would require me to change mail clients.
Changing the shortcut to 'Ctrl' + '/' would be fine, (with a corresponding entry on the 'Edit' menu).  Hopefully, no one is objecting to this solution (I didn't see such in the comments), so that we can put this one to bed?
(In reply to comment #56)
> > 'Find in this message' functionality is very old, well known, and intuitive...
> > In most programs CTRL+F invoke some kind of "Find" function.
> 
> For you maybe. Like I said, of the 50+ people here that I polled, only about 4
> of them even knew it existed, and they said they *never* use it.
> 
> When I asked about the Quickfilter, every one of them said they use it *all the
> time*, dozens if not hundreds of times a day.

So, you prefer sticking the new state of things for new users who just started using a recent feature, and, ask people who have 10y habits to change their old habits ? That's called "revolution". Please new users, and break things for the other ones.

> I'd be ok with that, since most people never click in the actual email body
> when reading a message, so in almost all cases, CTRL-F would toggle the QFB.

That would be a feature breakage.

It's 15y my computer powers-up when i press the power button; what about if since today, it decided that i need to paint a pink elephant to power-up ? And I only started to use computers 15y ago; ^F keybind was used way before i start computing.

There are 26 letters on a keyboard. Don't tell me no other letter is available, or that we can't steal the letter from an other <<less used feature>> than a search !!! For example, ^I ^B ^U that are used for italic, bold, and underline, are specific to "editors", and are irrelevant in a reader; are they already used in the main TB interface ? same question for the rest of the remaining 22 letters.

Or maybe, we could use just a single letter (like A for Archive, we could use F or S for search ?) ...

I agree about focus; using focus is a bad idea.

> There could also be other shortcuts besides ctrl+f for find in message that
> make more sense if people have more ideas about that.

The very first time i started TB3, i hitted ^F, started to type the text to search in my message, and "oh, it's not typing my text in the search, did TB3 break already the search engine ?".

... or maybe, we could just, at last, implement a REAL keybind editor !!! and let each user decide how they want things. All Window Managers (except Microsoft ones of course) let the user custom every single key as they want; xmodmaps let us remap everything; most apps also let the user custom things (Eterm, xchat, irssi ... have a keyind conf file); why are most keybinds hardcoded in Mozilla products ?

> Dropping the 'FIM' entirely would require me to change mail clients.

They are not dropping the feature, but, at least, moving it to an other keybind, or maybe (i hope they won't do that), remove compleetely the keybind and ask you to click in menus.

> Changing the shortcut to 'Ctrl' + '/' would be fine

No. It's fine for you, because you are probably using an US or UK keyboard. On my french board, the slash is above semi col. To perform Ctrl+/, I would actually press CTRL+SHIFT+':' keys, what could be interpreted literaly as a <<shifted control>> ... we don't want to walk on the borderline. Messing with shift is known to fail randomly (it even may depend on the Window Manager on Linux; and I would not be surprised about even more problems on Mac).

Why not let ^F for IMS as things are since years, and put the new QF on / (single key for US people) ?
> Or maybe, we could use just a single letter (like A for Archive, we could use F
> or S for search ?) ...

S is taken for Save.

> 
> Why not let ^F for IMS as things are since years, and put the new QF on /
> (single key for US people) ?

maybe CTRL+Q for QFB?
That's taken for "Quit" already on platforms other than Windows. I assume that localizers would be able to change the keyboard shortcuts as appropriate for their locale, thus also taking into account the location of special characters (where Ctrl and Shift buttons would be specified and fixed in the XUL code
though and thus equal for all locales, not sure if this would imply Ctrl+7 as noted in comment #17).

BTW: As I noted above, Ctrl+B (as in "bar") is still available. Another option might be to get rid of the quick find in message "/" shortcut and use "/" for "Find in This Message", given that these two functions are almost identical.

Either way, I'd suggest investigating how to spin off QFB from cmd_find to get started on the main issue while in parallel finding suitable keyboard shortcuts to make everybody happy.
/ is intuitive only to Vim, and recent Firefox users who installed some plugins. ^F is way older. Don't tell me there is not available letter; don't tell me we have to override and break an old feature.
My preference is Ctrl+B for QFB and Ctrl+F/Ctrl+G for "Find in this message".

@asuth: Any estimate on the effort needed to separate QFB from cmd_find, including updating tests, etc.? It appears that you are the best qualified
for that task. ;-)
Assertions that Quick Find would be used more than Find in Message are disputed by the fact that all six bug reports closed as duplicates of this one complain about getting Quick Find when Find in Message was what the user wanted.
(In reply to comment #60)
> So, you prefer sticking the new state of things for new users who just
> started using a recent feature, and, ask people who have 10y habits to
> change their old habits ? That's called "revolution". Please new users,
> and break things for the other ones.

New users? We've been using Thunderbird exclusively in our office for email since about version 0.8, so please stop making ass-u-me-ptions.

> I'd be ok with that, since most people never click in the actual email body
> when reading a message, so in almost all cases, CTRL-F would toggle the QFB.

> That would be a feature breakage.

This 'feature' is *already* broken, which is why this bug even exists. Just because *you* are used to it doesn't change the fact that it causes massive confusion for both new and long time (though maybe less technically inclined) users.

Also, this problem is related to *new* functionality - the new QFB.

Like I said - I don't have a problem with keeping CTRL-F for 'Find in this message', as long as a similarly simple (but separate* key combo can be assigned to the QFB.

> ... or maybe, we could just, at last, implement a REAL keybind editor !!! and
> let each user decide how they want things.

The few times I've suggested this sensible suggestion it was quickly shot down for whatever reason... apparently the devs who matter simply do not like the idea.

> Why not let ^F for IMS as things are since years, and put the new QF on /
> (single key for US people) ?

I'd be ok with that too - again, as long as these are separated, I'm fine with it.
(In reply to comment #65)
> Assertions that Quick Find would be used more than Find in Message are
> disputed by the fact that all six bug reports closed as duplicates of
> this one complain about getting Quick Find when Find in Message was what
> the user wanted.

And assertions that bug reports are indicative of 'normal user patterns' are disputed by the fact that the *vast* majority of users have no idea what a bug tracker is, let alone are willing to take the time to use it.

Maybe others use it (find in message) more than my admittedly small user poll suggests - but this is irrelevant, since no one is suggesting losing the ability, we're just trying to figure out how to sanely fix the current mess caused by the sharing of a single keybd shortcut for two different search types.
(In reply to comment #67)
> (In reply to comment #65)
> > Assertions that Quick Find would be used more than Find in Message are
> > disputed by the fact that all six bug reports closed as duplicates of
> > this one complain about getting Quick Find when Find in Message was what
> > the user wanted.

> Maybe others use it (find in message) more than my admittedly small user poll
> suggests - but this is irrelevant, since no one is suggesting losing the
> ability, we're just trying to figure out how to sanely fix the current mess
> caused by the sharing of a single keybd shortcut for two different search
> types.

Just leave old "find in mesage" on old key combo, and make new key combo for QFB.

This bug essentially has been made by developer who assign old, already used CTRL+F to new QFB functionality.
> (comment #40) Can we aim for a solution targeting 3.2 here?

Since according to today's meeting minutes TB 3.2 may or may not come and focus now shifts towards trunk development, I'm co-nominating this for 3.3 as well. Obviously, judging from comments and duplicates, it's a major usability issue.
Flags: blocking-thunderbird-next?
blocking-thunderbird5.0: --- → ?
Flags: blocking-thunderbird-next?
Hi, got the same problem.
I've just upgraded from 3.0.something to 3.1.7 and this new behaviour is really confusing.
I've been using Ctrl+F for searching within the current doc/email/webpage/... all the time and suddenly it does not work.

Not to mention that there is probably a flaw in the menus which go as follows:
Edit / Find / Find in This Message... CTRL+F
Edit / Find / Find Again... CTRL+G

Additionally, I've found the CTRL+G way for searching within a message, however I CANNOT change the string I'm looking for at the moment as the text field does NOT appear again (restart NEEDED).
Correct, Ctrl+G is not a suitable workaround:

(Quoting bug 575018 comment #5)
> I've just tried using Ctrl+G only for Find in Message - it opens nicely the bar
> the first time to enter the search term and will then continue finding that
> string. However, after closing the search bar with ESC, further Ctrl+G will
> continue searching the same string in that message and any other message I go
> to. Thus, apparently two different shortcuts will remain required for this.

        Attachment #512732 -
        Flags: review?(bugmail)

    
    

    
  
Comment on attachment 512732 [details] [diff] [review]
Show FindToolbar if message pane gets focus.

Per comment 55 Bryan explicitly does not want the keyboard shortcut based on focus.

If you read it differently to me, feel free to re-request ui-review from him. I think whatever patch is proposed for this bug definitely needs his ui-review approval before a standard review.

        Attachment #512732 -
        Flags: review?(bugmail) → ui-review-

    
    

    
  
Yack, after an Ubuntu 10.04 update to Thunderbird 3.1.8, ctrl+f is suddenly no longer working to find text within a message body. This is *very* frustrating. Trying ctrl+g doesn't let me enter a new search phrase either. It would be great if we can have the old behaviour back, or at least an option to revert to it. Thanks.

James.

    
    

    
  
James, this means Ubuntu has more energy to hack the source than the moz team (at least regarding this issue), but, this BTS does not care at all about distro specific issues or fixes. Especially if the distro patch is to remove a feature we all agree to keep (did they update the shortkey description in the menus for search in body ? ).

unless of course, if some distro provides a patch that would fix this bug, a way compatible with what's been said earlier.

    
    

    
  
Thanks. I'm not 100% sure if we have understood each other, but apologies if I was commenting on something Ubuntu did to Thunderbird -- it sounded like this bug report was describing the same issue I am seeing (with ctrl+f now activating a search messages box instead of the body text search, which no longer works). Of course the fact that the application behaviour has changed when applying what should have been a minor bugfix update must be an oversight on Ubuntu's part. To answer your question (I hope), the find menus still say "Find In This Message Ctrl+F" and "Find Again Ctrl+G".

    
    

    
  
Do they differenciate ^f from ^F ? would be tricky, but interesting approach.

    
    

    
  
Ctrl-Shift-F brings up the Search Messages window as previously.
blocking-thunderbird3.2: ? → ---

    
    

    
  
Hm.  Just come in on this and I start to understand a bit more why TB is, IMHO, so desperately slow solving bugs!  That's not to criticise what's gone on here but to me it seems that a bugzilla discourse is not an efficient way to solve UI and UI logic problems.  I was under the impression that search-in-message had been cut off from the UI by the addition of the quick search bar as an unplanned muddle with ctrl-F becoming an overloaded keyboard short cut.  I thought that because ^F (easier shortcut!) was getting me the quick search bar and I simply hadn't hit ^F again to discover that it still got me to the search-in-message (which is really, really helpful to me as, like others here, I often have huge long messages where I know exactly what I need to find or to check that it's not there).   One thing that added to the confusion for me was that sometimes if the message is not opened in a separate window then using the menus through Edit doesn't show a find option (hm, can't replicate that now but sure it was true).

Expecting us to know we have to use ^F twice to get what it used to do is surely not good UI upgrading.  I suspect you/we need a message that pops up where a default keyboard shortcut gets more complex that explains the change and has the checkbox on "Don't show this message again."

Incidentally, the quick search is brilliant and I use it a great deal as is the global search.

Tangential request: I can't find a public description of the structure of the TB project and its processes anywhere.  I've just done a lot of searching in from the Mozilla portal and that shows that TB is very much a minor project in terms of exposure there, I got, with some difficulty, to the listing of the TB team and their blogs and most of those have way old entries and some of those are more about the people than the project.  I can now see that there's a lot of work on the patch check in and testing but any sense of how the overall project has direction and how beta testing works is not accessible.  Is there a public warehouse of that sort of project information in readable and current form anywhere?

Thanks,

Chris

    
    

    
  
(In reply to comment #82)
> I was under the impression that search-in-message
> had been cut off from the UI by the addition of the quick search bar as an
> unplanned muddle with ctrl-F becoming an overloaded keyboard short cut.  

It was not unplanned, in the sense that iiuc the choice was consciously made to overload ^F because it was assumed "find X in this message" is used rarely and it would not be a great loss/inconvenience to make ^F invoke quick filter on the first hit.

> thought that because ^F (easier shortcut!) was getting me the quick search bar
> and I simply hadn't hit ^F again to discover that it still got me to the
> search-in-message (which is really, really helpful to me as, like others here,
> I often have huge long messages where I know exactly what I need to find or to
> check that it's not there).   One thing that added to the confusion for me was
> that sometimes if the message is not opened in a separate window then using the
> menus through Edit doesn't show a find option (hm, can't replicate that now but
> sure it was true).
> 
> Expecting us to know we have to use ^F twice to get what it used to do is
> surely not good UI upgrading.  I suspect you/we need a message that pops up
> where a default keyboard shortcut gets more complex that explains the change
> and has the checkbox on "Don't show this message again."

The ultimate reduction in confusion will come by not overloading ^F


> Incidentally, the quick search is brilliant and I use it a great deal as is the
> global search.
> 
> Tangential request: I can't find a public description of the structure of the
> TB project and its processes anywhere.  

https://wiki.mozilla.org/Thunderbird/ leads to all things THunderbird

    
    

    
  
correction https://wiki.mozilla.org/Thunderbird  (no slash on the end)

    
    

    
  
(In reply to comment #83)
> The ultimate reduction in confusion will come by not overloading ^F

What do you mean? The reason why this bug (and others duped to it) was filed is exactly the ambiguity of the same keyboard shortcut (and even the menu) doing two different things depending on in which focus or context you happen to be.

    
    

    
  
Oops ... and my ultimate confusion came from missing "reduction" in "by not", so obviously we are on the same track here. Sorry for the too quick reply.

    
    

    
  
Just to clarify, pressing Ctrl+F twice typically does not work for me in Ubuntu 10.04 with Thunderbird 3.1.8. The cursor just remains in the new quick search box. Sometimes it does switch to the message body though and I'm having trouble understanding the circumstances under which it does/doesn't work (will post again if I figure it out).

    
    

    
  
will this (the command and key changes) need any string changes that must be landed by May 10?

    
    

    
  
Yes, quickFilterBar.textbox.emptyText.keyLabel* defines what's shown in the
empty quick-filter box; I'd assume a similar construct for the Gloda search. Those are hard-wired, thus need to be changed along with the keyboard shortcut.

    
    

    
  
We're not going to block on this for 3.3, but we're going to be looking at resolving it soon (hence the UXPrio flag).
blocking-thunderbird5.0: ? → -
Whiteboard: [gs] → [gs][UXPrio]

    
    

    
  
And just to give some UX direction on this, I think the best way forward is to keep ctrl-f for the Quick Filter Bar, since that's what it seems to me most of our users are trying to do when they search.

But, we should definitely remove the double-ctrl-f, as that's confusing and hard to discover, and instead use the currently-unused ctrl-/ to find in the message.  It's got precedent, since / is already quick-search.

rsx11m, would you consider whipping up a quick patch that did implmented that, in the hopes of getting it in 3.3?

Thanks,
Blake.

    
    

    
  
I hope this type of feedback isn't unwelcome here(?), but may I point out that ctrl-f is used for the same search functionality as "find in this message" in Firefox (it searches in the page body and has the same GUI bar etc.). I'm not sure what your policy is regarding consistency between the apps, but changing to ctrl-/ seems bound to cause some confusion (though it's better than not having a working keystroke at all in my case).

Cheers,

James.

    
    

    
  
Friendly feedback is almost always welcome.  :)

I did consider that, and certainly the pairing of ctrl-f and ctrl-g for searching the same way was one of the main arguments for having ctrl-f search the text of the message, but I feel that when people search for messages, what they're more often trying to do is better expressed by the Quick Filter Bar, and that seemed more important than cross-application consistency.  (And Firefox doesn't have anything like the Quick Filter Bar for us to compare with, so the analogy kind of breaks down at that point. :)

Thank you for your input,
Blake.

    
    

    
  
(In reply to comment #91)
> rsx11m, would you consider whipping up a quick patch that did implmented
> that, in the hopes of getting it in 3.3?

Sorry, no. I would have posted a patch already if I knew how to untangle those (modulo shortcut definitions which aren't clear yet), but given that I haven't been working on search-related code at all (with the exception of porting a simple SeaMonkey patch at some time) I quickly had to give up on that effort.

    
    

    
  
One thing I'd considered is using Ctrl+Shift+F for the quick filter. This would mean that the more-complicated "Search Messages" dialog wouldn't have a hotkey, but maybe we could add a button to the quick filter bar to "upgrade" to the more-advanced dialog. Or we could pick a different hotkey for it. I expect that we want to encourage the quick filter over the Search Messages dialog wherever possible anyway.

    
    

    
  
I agree with Comment 92 - as an end-user, I've always been surprised that ^F didn't open the "Search this message" box, and pass focus to it.  After all, the message body feels like a browser page, to me anyway - and this is the experience with FF, IE and GC browsers.   I think there should be a different shortcut for the quick filter bar, which is not found in browsers.

    
    

    
  
Thanks, Blake. Re. Jim's comment #95, as someone who preferred ctrl-f for "search in message", I also frequently use ctrl-shift-f for "search messages" (just one data point). I wonder if ctrl-/ is adopted, could it also be introduced as an alias for ctrl-f in Firefox?

For some reason I'm noticing that the delay in moving to the quick search box with the mouse bothers me less than moving to the find in message box, even beyond the latter not being visible by default and needing 3 menu selections to show up. Not sure whether that's just me being eccentric or might be interesting...

    
    

    
  
It pains me to be weighing in on this because most of the choices are fraught with cons. But moreso because of my respect for the UX folks who have more experience in UI than most dudes and dudettes, plus the other people who have already commented ...

But to put it mildly I'm really not keen on ctrl+/.  I doubt it or browser quick search is known by most of mankind, i.e. average users. (indeed it's not exposed in FF UI. And I thought that feature was on it's way out several years ago.) Plus ctrl+/ has no logical connection to ctrl+g (find again) as ctrl+f does. Or, will ctrl+/ somehow also provide find again capability?     *But most importantly ctrl+/ in FF now maps to apps bar ... which I would think, Thunderbird will be wanting in the not to distant future.*  

ctrl+F is ubiquitous in windows finding text in content - not across multiple files.  And (I have trouble putting this in words) people used ctr+F for years for search in message.  I don't see how we arrived at the rational for using it for filter.  (except "F" for filter. but we have plenty of keys that don't have a strong bond to their written assignment)

which brings me too ...

ctrl+shift+k  for filter (a mimic of ctrl+k for global Search All) and leaving ctrl+F to "find" seems to me an elegant choice all around. (heck, filter and global were even in the same field at one point)

    
    

    
  
Russel:
Any change like this will bother some users, it's true, but Thunderbird isn't a browser (yet), and has a slightly different usage model, so we can't just use the browser keybindings wholesale, and in this case, the idea of "searching" makes more sense on a cross-message context by default.

Wayne:
Fraught with cons, indeed.  :)  I think we can all agree that there's no perfect choice here, just a set of trade-offs.  Ctrl-/ isn't my first choice for "Find in Message", but it does seem to me that finding text in a message is a relatively rare operation, and finding a message in the list is much less rare, and so should be the default search operation.

The thing I don't like about ctrl-shift-k is that that's what the gloda empty-text already shows, and showing people "Ctrl-K" but meaning "Ctrl-k" is really confusing.

Of course, once we get some data on actual usage, I'm happy to revisit this decision, but until then we're blindly stabbing (or being stabbed ;) in the dark, and that's not a good way to try and figure out this type of thing.

(And hey, look at the good side, perhaps by us adding this shortcut we'll draw attention to the quick search feature, and get more people using it.  :)

Thanks,
Blake.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Use Ctrl+/ for "find in message" (obsolete)
        — 
          — Splinter Review
      

    


  
Ok, I *think* this is correct. I didn't add any tests, since I'm not sure I'd be able to do all that before string freeze, but it seems to work based on my limited tests.

Note that I chose to make Ctrl+F toggle the quick filter bar. Maybe that's the right thing, maybe it's not (it is different from how the Find bar works in Firefox).
Assignee: nobody → squibblyflabbetydoo
Status: NEW → ASSIGNED

        Attachment #531210 -
        Flags: review?(bwinton)

        Attachment #531210 -
        Flags: feedback?(bugmail)

    
    

    
  
Comment on attachment 531210 [details] [diff] [review]
Use Ctrl+/ for "find in message"

Review of attachment 531210 [details] [diff] [review]:
-----------------------------------------------------------------

A test is required for this yes, especially as this patch most likely breaks the existing mozmill keyboard test for the current logic.  (Specifically, it tests that control-f transfers focus if hit a second time, and also tests that control-f transfers focus in the first place, which this patch does not appear to enforce, although things could luck out.)

I would argue against making the keybinding have a toggling behaviour on the quick filter bar because we stole the 'escape' key binding for the purpose of relaxing qfb constraints and eventually closing it, so it seems like it would just complicate mental models.  Also, if we're cribbing from firefox, hitting control-f repeatedly can be used to select-all the contents of the text-box, which does seems usefully in terms of idempotence.

        Attachment #531210 -
        Flags: feedback?(bugmail) → feedback-

    
    

    
  
Comment on attachment 531210 [details] [diff] [review]
Use Ctrl+/ for "find in message"

(I'll defer to asuth on this, and clear out my review.)

        Attachment #531210 -
        Flags: review?(bwinton)

    
    

    
  
For consistency with the Firefox-style Find function, should we move View -> Toolbars -> Quick Filter Bar to Edit -> Find -> Quick Filter? The Quick Filter Bar menu item is a checkbox, so it should toggle, but it lists the keyboard shortcut for "show the quick filter bar", so they're not really the same action.

Alternately, we could remove the shortcut from the menuitem and have it behave as it currently does. The shortcut would still be listed in the textbox for the quick filter bar.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Address review comments (obsolete)
        — 
          — Splinter Review
      

    


  
In this version:

* Ctrl+/ is used for "find in message"
* Ctrl+F is used for "expand quick filter bar"
* Hitting Ctrl+F when the quick filter bar is expanded focuses the text box and
  selects the text 
* View -> Toolbars -> Quick Filter Bar doesn't show Ctrl+F anymore, since it's
  not the same as hitting Ctrl+F
* Tests updated

        Attachment #531210 -
        Attachment is obsolete: true

        Attachment #531254 -
        Flags: review?(bwinton)

        Attachment #531254 -
        Flags: feedback?(bugmail)

    
  
Whiteboard: [gs][UXPrio] → [gs][UXPrio][affects l10n]

    
    

    
  
Comment on attachment 531254 [details] [diff] [review]
Address review comments

Review of attachment 531254 [details] [diff] [review]:
-----------------------------------------------------------------

There's a bug in here somewhere.

Steps to Reproduce:
Ctrl-F, type some stuff, Ctrl-F (the text is selected), Ctrl-/

Expected result:
The Find in Message would appear and be focused.

Actual result:
The Find in Message didn't appear.

So, given that, and the stuff I mention below, I think I've got to give this an r-.

Sorry about that,
Blake.

::: mail/locales/en-US/chrome/messenger/messenger.dtd
@@ -276,4 +276,4 @@
> >  <!ENTITY findMenu.accesskey "F">
> >  <!ENTITY findCmd.label "Find in This Messageâ¦">
> >  <!ENTITY findCmd.accesskey "F">
> > -<!ENTITY findCmd.key "f">
> > +<!ENTITY findCmd.key2 "/">

> > +<!ENTITY findCmd.key2 "/">

I think we prefer "findCmd2.key" for this.
or "findInMessageCmd.key"

::: mail/test/mozmill/quick-filter-bar/test-keyboard-interface.js
@@ +183,1 @@
>  }

I think we should keep testing the escape behaviour (in particular that it closes the QFB, and not the find-in-message bar).

Of course, that raises a second problem with this code.  I can hit Ctrl-/ to open the find-in-message bar, but if I have the QFB open, and hit escape to close it, I can't hit escape to close the find-in-message bar.  (Actually, it looks like the QFB still has focus if I close it.  See http://dl.dropbox.com/u/2301433/Screenshots/MissingQFB.png for an example of other weirdness.)

        Attachment #531254 -
        Flags: review?(bwinton)

        Attachment #531254 -
        Flags: review-

        Attachment #531254 -
        Flags: feedback?(bugmail)

    
    

    
  
(In reply to comment #105)
> Of course, that raises a second problem with this code.  I can hit Ctrl-/ to
> open the find-in-message bar, but if I have the QFB open, and hit escape to
> close it, I can't hit escape to close the find-in-message bar.  (Actually,
> it looks like the QFB still has focus if I close it.  See
> http://dl.dropbox.com/u/2301433/Screenshots/MissingQFB.png for an example of
> other weirdness.)

Bug 625472 is about the QFB still keeping focus.  It does make sense to fix that with this bug, though.

    
    

    
  
It looks like Ctrl+/ is used as an alternate shortcut for "select all". I have no idea where this is being defined, though.

    
    

    
  
The quick filter feature CAN be compared to firefox on one point: a non existing feature I am thinking about since long time, and did not querry yet. A feature that used to exist in firefox up to 2, and that have been removed from FF3: the search filter in the bookmark editor. I hate FF3 any way, because of too many feature drop, and several security issues that will never be fixed. But if you remember of FF2, or still have it somewhere ... you can compare the bookmark search engine with quick filter of TB. I used it quiet often. And I am missing it. The actual URL completion sux too much for me: history is too short (less than 1 year, dispite my 9999 days set up in the conf), and does not scan the bookmarks.

They are similar because ... the keyword is to be searched in the title/name of content (head of page, subject of email), and then, you must click on the single line result in order to view a full page content on screen.

They are very similar to me.

Thus, I also vote for ^F search in BODY PAGE CONTENT in both application; i am not  against the quick filter; I am against the quick filter on ^F !!! put it any other place you like. Can not compare with FF3 since -it sux- it dropped the feature.

    
    

    
  
Hear hear!   this is what end-users expect, ^F to search the body content.

    
    

    
  
Russell - just because you work a certain way doesn't mean everyone does...

I virtually *never* use 'find in message', and use the quickfilter *all the time*...

I say it should simply be configurable - let the user decide which search action Ctrl-f applies to, and whatever other keyboard shortcut is decided upon will automatically apply to the other one.

    
    

    
  
matter of fact, I don't use search-the-content all that much either, and like you, I search through the messages using Gloda or the QuickFilter.  

BUT, whether or not I use it or not is beside the point.  My point is, if software establishes a UI gesture, you should really keep it that way, or provide a really cool alternative way of doing the same thing.   Otherwise you cause confusion.   Remember, that's how TB 2.x did it, not to mention all browsers that I use, not to mention all editors and spreadsheets - what's left?

Personally, when I think of using ^F at all, and it doesn't do what I thought it would, it is just a bit irritating, and I have to think about it - that's all.   Oh, and ^/ is not really all that cool IMHO.   Anyway, enough said.

I guess the really important thing is, that ^F no longer has a conflict, which is what this bug is really about.   :-P

    
    

    
  
The main problem being that a decision on the shortcuts will have to be made by midnight PDT tonight as it's the cut-off time for any string changes, assuming that the issues noted in comment #105 can be resolved.

BTW: I'm fine with moving Ctrl+K to the quick-filter bar and make the Gloda search bar Shift+Ctrl+K instead if anything else doesn't work out, this would make it look quite consistent (no Shift = use lower, with Shift = upper bar).

    
    

    
  
(In reply to comment #112)
> The main problem being that a decision on the shortcuts will have to be made
> by midnight PDT tonight as it's the cut-off time for any string changes,
> assuming that the issues noted in comment #105 can be resolved.

We've made the decision that given where we are we're not going to rush this into the next release, the release after should be about 8 weeks, so we can pick up a fix then.

    
    

    
  
So, if I read this correctly, it would give us 14 days from now to finalize:
https://wiki.mozilla.org/Thunderbird/StatusMeetings/2011-05-10#Schedule_and_Progress
Otherwise it'll be missing 3.4 too. If the patch works except for the keyboard shortcuts (assuming that Ctrl+/ won't work), that sounds feasible.

    
    

    
  
I must disagree with the idea of using Ctrl-F for Quick Filter.  Before there was a Quick Filter, Ctrl-F meant Find in This Message.  That design should be restored.  As I noted in comment #65, many bug reports closed as duplicates of this one resulted from Ctrl-F becoming "broken" by its use for Quick Filter.  

In the Mozilla-based browsers, Ctrl-F means Find in This Page.  Consistency of use indicates that, for Thunderbird, it should mean Find in This Message.  Using it for Quick Find can only create confusion for those using more than one Mozilla-based application.

    
    

    
  
Blake, Jim: Any conclusion on the keyboard shortcuts? Plenty of suggestions here to pick from, and the next release train leaves the depot in two days...

From Mark's post in tb-planning:
> Hence Miramar.next will be string complete on 24th May, and feature
> complete (unless features are backed out/disabled). [snip]
> The next train would start 6 weeks after, i.e. 5th July.

    
    

    
  
(In reply to comment #116)
> Blake, Jim: Any conclusion on the keyboard shortcuts? Plenty of suggestions
> here to pick from, and the next release train leaves the depot in two days...

I like the direction of Jim's last patch, but there were a couple of bugs in it, which is why it got an r-.  I'm happy to re-review it once those are fixed.

Later,
Blake.

    
    

    
  
I thought the main problem with this patch was that Ctrl+/ is bound already elsewhere, thus it didn't work as expected. That part would be subject to the upcoming string freeze and thus needs to be clarified.

    
    

    
  
I don't believe it is.  It's just not as findable as Ctrl+F.

    
    

    
  
As mentioned before: on non-English keyboard layouts, e.g. German, Ctrl+/ is actually a three-key combo, as "/" is Shift+7, so Ctrl+/ resolves to Ctrl+Shift+7. Grrr.

    
    

    
  
Blake, see Jim's comment #107:
> It looks like Ctrl+/ is used as an alternate shortcut for "select all".

Given that there are other important reasons why it is not a good choice, I'd think that keeping Ctrl+F for "Find in this message" for consistency with other applications and moving the quick-filter bar to Ctrl+K, with Gloda moving to Ctrl+Shift+K still sounds like a good alternative. There should be no problem indicating the "+Shift" difference between those two in the text shown when the search bars are empty and not focused.

    
    

    
  
(In reply to comment #120)
> As mentioned before: on non-English keyboard layouts, e.g. German, Ctrl+/ is
> actually a three-key combo, as "/" is Shift+7, so Ctrl+/ resolves to
> Ctrl+Shift+7. Grrr.

Did you ever heard of digipads ? you know ... I am french, and / is shifted ':' ... but we also have a / on the digipad. Aif you put your right thumb on the right Ctrl, then you can easily put your 3rd finger on the / of digipad ... keeping ^/ a 2 key combo.

Unless you want to keep the thing a two key combo for all keyboards, including laptops, and why not also mobile phones ? but it will be very hard to have only two keys combos on all laptops and mobiles phones, because by essence they have less keys than standard computers.

Or ... you could just solve the problem at the root, where the problem *REALLY* lays: stop doing hardcoded binds (the evil of source-hard coded stuff have been prooved and explained 20 years ago), and introduce a real modern keybind manager like in all propre Window Managers (exit Windows: Gnome, KDE, E16, E17, *box) and all proper modern apps (Gimp, OOo ... ).

Non english people are not retarded. So, next time, either explicitely state what you assume, or what you ignore (either "don't know", or, deliberatly do not take into consideration).

And for the french keyboard in particular, ^/ on my laptop is really easy: Dell lattitude D610 (on which Ctrl and Shift are too far and can not be pressed with the same finger), thumb on Ctrl, 5th finger on shift, 2nd finger on 7 ... not so hard. And for my french layout on workstation, 5th finger to press Ctrl and Shift at the same time, 2nd finger on ';' to get '/' ...

Or we can keep doing nothing for ages ... and just chat about ethic.

I could not imagine it would be possible to make such a big deal from such a small issue.

Leaving bug.

    
    

    
  
(In reply to comment #121)
> Blake, see Jim's comment #107:
> > It looks like Ctrl+/ is used as an alternate shortcut for "select all".

Not on the Mac, Windows, or Linux boxes I tried…

    
    

    
  
(In reply to comment #105)
> Steps to Reproduce:
> Ctrl-F, type some stuff, Ctrl-F (the text is selected), Ctrl-/

This is the problem, I can reproduce in 3.4a1pre on Linux but not on Windows. The issue appears to be that the search bar, which has focus when you enter something, considers Ctrl+/ as an Ctrl+A equivalent for some reason and will highlight the entire text. So, that widget may override any key definition of Ctrl+/ outside that context.

Jim, can you double-check and confirm whether or not Ctrl+/ is usable?

    
    

    
  
I'm afraid I really find the present assignment, which overloads one keybinding with too much responsibility, to be just really annoying to use.

I would greatly prefer for Ctrl+F to be restored to 'Find in this message'.  Ctrl+G is to 'Find next in this message'.  You can make it Ctrl+Alt+F and Ctrl+Alt+G for Quickfind and Quicknext, and as at present, Cltr+Shift+F to open the Search Messages Form.  Esc can continue to close whatever is currently open.

    
    

    
  
(In reply to comment #127)
> I'm afraid I really find the present assignment, which overloads one
> keybinding with too much responsibility, to be just really annoying to use.
> 
> I would greatly prefer for Ctrl+F to be restored to 'Find in this message'. 
> Ctrl+G is to 'Find next in this message'.  You can make it Ctrl+Alt+F and
> Ctrl+Alt+G for Quickfind and Quicknext, and as at present, Cltr+Shift+F to
> open the Search Messages Form.  Esc can continue to close whatever is
> currently open.

Ctrl+Alt combinations are bad, since they break things in strange ways in non-English locales (unfortunately, I don't recall the details).

If someone wants to figure out why Ctrl+/ acts as "select all" in textboxes, I can push this forward, but I have no idea whatsoever where that accelerator is being set, so I can't do much with it at the moment.

    
    

    
  


  
Menu states "Find in this message" but when invoked, it brings up QuickFind instead.  One needs to press Ctrl+F again to Find in this Message, and then Ctrl+G for Find Next in this Message.  These are separate functions and should have separate keybindings, one for each.  I suggest Ctrl+F for Find in this Message, and Ctrl+Alt+F for Quickfind.  Ctrl+Shift+F already is reserved for the Search All Messages Form.

    
    

    
  
Comment on attachment 544596 [details]
menu wrongly describes what first invoking of Ctrl+F does

menu wrongly describes what first invoking of Ctrl+F does

Menu states "Find in this message" but when invoked, it brings up QuickFind instead.  One needs to press Ctrl+F again to Find in this Message, and then Ctrl+G for Find Next in this Message.  These are separate functions and should have separate keybindings, one for each.  I suggest Ctrl+F for Find in this Message, and Ctrl+Alt+F for Quickfind.  Ctrl+Shift+F already is reserved for the Search All Messages Form.

    
    

    
  
Double post sorry *129-130) caused because when I clicked Details, the field was blank so I posted into it what I had already done on this page.

    
    

    
  
The Alt key is reserved for accessibility using the keyboard instead of the mouse to navigate menus. If this includes Ctrl+Alt I don't know, but it may be rather confusing to mix the implications of the Alt key in this way.

Re comment #129: Yes, the menu keys will have to be changed in the XUL code along with the underlying separation of the commands.

    
    

    
  

      
      
      
      

        Attached image
          
        Edit>Delete Message has no keybinding (obsolete)
        — 
      

    


  
Another related issue is the change in behaviour of the delete key when in the If one has the Search This/All message field in focus, then it is necessary to press Esc once or twice to exit the search field(s) to back track to the message lis in order to be able to delete the message by using the Del or Backspace key.

While it's obviously necessary for these keys to work as editors in a text editing field, as deleters of text, it would be useful for a keybinding to be assigned to currently unkeybound Edit>Delete Message.  A quick hunt through the menus suggests that D might be available.

    
    

    
  
Comment on attachment 544772 [details]
Edit>Delete Message has no keybinding

That's off topic in this bug, please file your own report if none exists yet.
It also seems to be specific to Mac OSX as I can't reproduce on Windows.

        Attachment #544772 -
        Attachment is obsolete: true

    
    

    
  
After several long chats with people whose opinions I respect, I think I've changed my mind on this.  While I still believe that when people are trying to find stuff in Thunderbird, what they are most often trying to find are messages, not text within a message, I now also believe that Thunderbird has too much legacy to be the place for this kind of change.

As mentioned previously, we also can't use Ctrl+Alt combinations, since they break things in strange ways in non-English locales.

Ctrl-Shift-F is also already taken, and without any data on how many people use any given key combination, I'm not going to entertain suggestions of breaking any more of them.

As far as I can tell, that leaves us with:
Find in Message - CTRL + F
Search Messages window - CTRL + SHIFT + F
Find Next - CTRL + G
Find Previous - GTRL + SHIFT + G
Global search - CTRL + K

and finally,
Quick Filter Bar - CTRL + SHIFT + K (currently unused).

    
    

    
  
Since we've decided on alternate keybindings, my patch above should work with minor tweaks. I'll try to update it in the next couple days (someone ping me if I haven't uploaded a patch by Friday).

    
    

    
  
I think that's great news from Blake. Apart from the long legacy and compatibility with Firefox, other applications have adopted these keystrokes for "find in body", eg. the PDF reader in GNOME, just as an example. Even OpenOffice uses it for find and replace.

    
    

    
  
I think you might all be amused by the fact that I tried to search for some text in a message this morning, and was confused for a second when I hit Cmd-F and typed "Canada", only to see all my messages disappear…

Later,
Blake.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Use the new keybinding (obsolete)
        — 
          — Splinter Review
      

    


  
This patch is pretty much like the previous, with different keybindings. See comment 104 for information about the previous patch.

        Attachment #531254 -
        Attachment is obsolete: true

        Attachment #545813 -
        Flags: review?(bugmail)

    
    

    
  
Comment on attachment 545813 [details] [diff] [review]
Use the new keybinding

Looks good by inspection.  I'm not sure I followed Blake's prose, but this does seem to implement the specified keybinding.

Thanks very much for seeing this through.

Note that the poorly explained "secret bonus test!" probably does not want to be removed.  The actual goal there was to clear the contents of the quick filter bar; right now you are leaving the filter active with "search string" in the box.  This does not pose a problem because it's the last test in the file and the qfb is not in a pinned mode so the required folder transition in any subsequent test file will clear it, but it seems preferable to still reset the state and just use a better comment.  Related to that, you still have a comment saying "control-f" earlier in the file.

        Attachment #545813 -
        Flags: review?(bugmail) → review+

    
    

    
  


  
Pulling forward r+. This patch fixes the issues in comment 141. Also, I found another file that referenced ctrl+F, so I fixed that too. A grep on the folder shows there aren't any more references to ctrl+F anywhere.

        Attachment #545813 -
        Attachment is obsolete: true

        Attachment #546058 -
        Flags: review+

    
    

    
  
Checked in: http://hg.mozilla.org/comm-central/rev/c7733cc3da46
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 8.0

    
    

    
  
Verified fixed in today's 8.0a1 nightly build on Windows 7.
Thanks!
Status: RESOLVED → VERIFIED

    
    

    
  
In which Thunderbird release can we expect to see this implemented?

    
    

    
  
Since the patch contains string changes (accelerator keys) which need to be added to the translations by the localizers, this won't qualify for either 6.0 (due mid August) or 7.0 (about six weeks after 6.0), thus it will come with 8.0 (in turn about six weeks after 7.0).

    
    

    
  
Briefing up, this trivial bug was detected early by a beta-tester, but allowed to make it into an official release, and it will be fixed 5 releases and 15 months later, and after an unspecified (big) amount of users have put pressure, opened 12 duplicates of the original bug, and commented it in the blogosphere.

Developers, listen to the users. Seriously.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Fix strings
        — 
          — Splinter Review
      

    


  
In retrospect, I should have changed the keys for the strings too, so that localizers pick up on the change. I also changed how the Mac shortcut is formatted, but I'm just guessing on that, since I don't use a Mac.

        Attachment #546464 -
        Flags: review?(bugmail)

    
    

    
  
Comment on attachment 546464 [details] [diff] [review]
Fix strings

I hear Blake has a mac!

        Attachment #546464 -
        Flags: review?(bugmail) → review?(bwinton)

    
    

    
  
This is marked as 'fixed' but I still don't like this implementation. I believe that there should be three separately available search within functions:
1. Search inside All Folders
2. Search in This Folder (as presently invoked with +F
3. Search inside This Message (as presently invoked with +F +F)
4. Advanced Search (as presently invoked with +shift+F)

Currently option 3 is accessible only through option 2, and option 1 only through option 4.  While it's easy enough to with 1 and 4 being co-dependent, having 2&3 co-dependent is just a darned nuisance.  If I am already inside a Folder, I don't need to search inside it before searching inside a message inside it.

There is also the annoyance that the Esc button works differently dependin upon where in the hierarchy of  +F you happen to be at the time.  Having distinct keybindings separate for each would sort this issue out in a heartbeat.

The present behaviour is downright annoying.

    
    

    
  
(In reply to comment #150)
> This is marked as 'fixed' but I still don't like this implementation. I
> believe that there should be three separately available search within
> functions:
> 1. Search inside All Folders
> 2. Search in This Folder (as presently invoked with +F
> 3. Search inside This Message (as presently invoked with +F +F)
> 4. Advanced Search (as presently invoked with +shift+F)
> 
> Currently option 3 is accessible only through option 2

Not anymore. That's what this bug fixed.

    
    

    
  
Thanks Jim, on re-reading back to comment 144, I realise it's going to be a while before we see it, but it's good to know we have that to look forward to in v.8

    
    

    
  
Comment on attachment 546464 [details] [diff] [review]
Fix strings

Review of attachment 546464 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.  It's odd that although I say "Command Shift K", it's actually written as "Shift Command K"…

(Just like it is in <http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/KeyboardShortcuts/KeyboardShortcuts.html#//apple_ref/doc/uid/TP40002725-CHDIGFBH>.)

r=me!

Thanks,
Blake.

        Attachment #546464 -
        Flags: review?(bwinton) → review+

    
    

    
  
(In reply to comment #135)
> After several long chats with people whose opinions I respect, I think I've
> changed my mind on this.  While I still believe that when people are trying
> to find stuff in Thunderbird, what they are most often trying to find are
> messages, not text within a message, I now also believe that Thunderbird has
> too much legacy to be the place for this kind of change.
> 
> As mentioned previously, we also can't use Ctrl+Alt combinations, since they
> break things in strange ways in non-English locales.
> 
> Ctrl-Shift-F is also already taken, and without any data on how many people
> use any given key combination, I'm not going to entertain suggestions of
> breaking any more of them.
> 
> As far as I can tell, that leaves us with:
> Find in Message - CTRL + F
> Search Messages window - CTRL + SHIFT + F
> Find Next - CTRL + G
> Find Previous - GTRL + SHIFT + G
> Global search - CTRL + K
> 
> and finally,
> Quick Filter Bar - CTRL + SHIFT + K (currently unused).

This all makes me very sad, I think this is like the worst possible outcome. This change throws out all training/muscle memory many people gained since TB 3.1 introduced the Quick Find Bar in June 2010. That this arguably very useful feature gets the last remaining, inconvenient keyboard shortcut, even losing out to the abandoned Search Messages dialog is hard to believe. I for one find it very jarring to use the current Thunderbird Nightlies...
Well, there's always Postbox, that's pretty affordable now. (sad to see what Scott McGregor is suddenly able to pull off, *after* leaving TB...)
Blocks: 625472

    
    

    
  
I think each of these functions needs a unique shortcut that doesn't require you to be in any part of a particular window for it to work:
Delete current message - can't be done by Del or Backspace if you're in a search field because then they delete text, you have to press Esc first, therefore needs a kbd shortcut that will work on any current email
Search inside message, can't currently be done in one keyclick; you have to have first pressed ctr F to search the message list, and then press it again - pointless if you've already got the message you want.
Search for next and for previous - in whatever is current, the list or the message
Search message list (keeping current filter buttons)

Each of these I believe needs to work without any drilldown, apart from of course being in a message window, or inside the message window.  The text editing keys BackSpace and Del when being used for text editing should not require Esc to be pressed before the entire message can be deleted.  There needs to be a Delete Message shortcut (it's in the Edit Menu already, but without a shortcut)

BTW the Status here states "Verified Fixed" but on the version I am on (6.01), this is not so.

    
    

    
  
PS - I recall now, from comment 143 and the TM that a new approach to this problem will eventually appear in a release version from 8 onwards.

    
    

    
  
(In reply to Thomas Stache from comment #156)
> (In reply to comment #135)
> > After several long chats with people whose opinions I respect, I think I've
> > changed my mind on this.  While I still believe that when people are trying
> > to find stuff in Thunderbird, what they are most often trying to find are
> > messages, not text within a message, I now also believe that Thunderbird has
> > too much legacy to be the place for this kind of change.
> > 
> > As mentioned previously, we also can't use Ctrl+Alt combinations, since they
> > break things in strange ways in non-English locales.
> > 
> > Ctrl-Shift-F is also already taken, and without any data on how many people
> > use any given key combination, I'm not going to entertain suggestions of
> > breaking any more of them.
> > 
> > As far as I can tell, that leaves us with:
> > Find in Message - CTRL + F
> > Search Messages window - CTRL + SHIFT + F
> > Find Next - CTRL + G
> > Find Previous - GTRL + SHIFT + G
> > Global search - CTRL + K
> > 
> > and finally,
> > Quick Filter Bar - CTRL + SHIFT + K (currently unused).
> 
> This all makes me very sad, I think this is like the worst possible outcome.
> This change throws out all training/muscle memory many people gained since
> TB 3.1 introduced the Quick Find Bar in June 2010. That this arguably very
> useful feature gets the last remaining, inconvenient keyboard shortcut, even
> losing out to the abandoned Search Messages dialog is hard to believe. I for
> one find it very jarring to use the current Thunderbird Nightlies...
> Well, there's always Postbox, that's pretty affordable now. (sad to see what
> Scott McGregor is suddenly able to pull off, *after* leaving TB...)

I must say I agree with this. I was holding off with upgrading from TB 3.1 for the longest time since I saw no benefit and the hideous glass UI (on Vista at least) really, really put me off. I found a nice theme the other day that makes TB 8.0 look similar to that of TB 3.1, so I decided to upgrade; if anything there would be under the hood improvements I could benefit from.

I haven't noticed much (if anything) a part from minor speed improvements, but this change bugs me to no end and I'm on the verge of going back to the 3.1 branch due to this alone. For me, Ctrl-Shift-K introduced a couple of things which I find very negative:

1) Another key to press, might not seem like much to some, but shortcuts should be as short as possible. I suspect this keyboard 'shortcut' is an extension of the regular "Search (Ctrl-K)" shortcut, but they behave very different so I don't even see why the shortcuts should be related.

2) Must use two hands, yet another slow-down and a very uncomfortable one. I could've easily adapted to Shift-F or Ctrl/Shift-Q (they currently do nothing AFAIK), but the new command is just awful ergonomics and takes much longer. Shouldn't even need to defend the benefit of a 'one hand shortcut' over a 'two hand SHORTCUT'.

Anyway, I hope you'll implement some easy way to change the keyboard shortcuts (since you obviously just change them). Now I'm off to see if there's a way to do this manually already via some unsupported hack. If not, I sadly need to go back to 3.1.

Sorry if this seemed like a rant, I just needed to vent my feelings on the issue.

    
    

    
  
(In reply to Chris from comment #160)
> Anyway, I hope you'll implement some easy way to change the keyboard
> shortcuts (since you obviously just change them). Now I'm off to see if
> there's a way to do this manually already via some unsupported hack. If not,
> I sadly need to go back to 3.1.

You're looking for the add-on called "KeyConfig", which will let you change (or even add) shortcuts to your heart's content. We're also thinking about redesigning our keyboard shortcuts (while still allowing people to use the old set), but we need some good stats first on what functions are used the most. That's bug 697723.

    
    

    
  
Customizable keyboard shortcuts should be bug 57805 and dependencies, it sure would resolve a lot of issues with inconvenient shortcuts.

See http://kb.mozillazine.org/Keyconfig_extension%3A_Thunderbird for a description of the add-on mentioned in comment #161, and it can be downloaded from the site linked to in http://forums.mozillazine.org/viewtopic.php?t=72994

    
    

    
  
NOT FIXED!

Latest release has made matters worse! Now the search in list feature has simply been removed.  This feature was valuable.  What wasn't was the short cut to it being the same as the shortcut to Search Inside Message.

The whole thing has never been properly implemented.  Search in all messages can only be achieved now with a separate Filter page, which we already had before.

Why not simply keep the Search In Message List feature, and change the shortcut to it?

Also, in the Search Inside Message feature, one cannot close the search field unless one re-enters it, and then presses Esc.

Someone needs to sit down and redesign the flow to this whole search system.

I did this already, but it got flagged as a duplicate of this page.

    
    

    
  
(In reply to Derek Williams from comment #163)
> Now the search in list feature has simply been removed.

I have no clue what you are talking about, no feature was removed in this bug.

> Why not simply keep the Search In Message List feature, and change the
> shortcut to it?

That's what was done here, though I still think there could have been a better reassignment of the keyboard shortcuts. Ctrl+F opens "Find in This Message" as before the quick-filter bar was introduced, and *new* Ctrl+Shift+K now opens and focuses the quick-filter bar (what you call "Search In Message List", or not?).

> Also, in the Search Inside Message feature, one cannot close the search
> field unless one re-enters it, and then presses Esc.

That would be a separate bug, you sure can file it as a follow-up to this one. However, using Ctrl+F to find a text, then using ESC to close it works for me.

    
    

    
  
Thank you for this clarification.  i was obviously a bit premature in posting!

    
  
Blocks: 702913

    
  
Blocks: 720379

    
    

    
  
Finally, this highly user-facing change is now fully and correctly documented in the main Keyboard Shortcuts documentation, with appropriate product version selectors for both old and new versions, as of major revision 5614 (1) which I landed today.

|-
|Quick Filter (search messages in current folder or view)||{for =tb31,=tb4,=tb5,=tb6,=tb7}{for win,linux}{key Ctrl+F}{/for}{for mac}{key Command+F}{/for}{/for} {for tb8}{for win,linux}{key Ctrl+Shift+K}{/for}{for mac}{key Command+Shift+K}{/for}{/for}
|-
|Find Text in Current Message||{for =tb31,=tb4,=tb5,=tb6,=tb7}{for win,linux}{key Ctrl+F} and then {key Ctrl+F} again{/for}{for mac}{key Command+F} and then {key Command+F} again{/for}{/for} {for tb8}{for win,linux}{key Ctrl+F}{/for}{for mac}{key Command+F}{/for}{/for}
|-

N.B.
- The odd {for =tb31,=tb4,=tb5,=tb6,=tb7} syntax for multiple subsequent versions excluding current version(s) is due to bug 720243.
- When creating such version-dependent markup, do *not* use "Show for..." button until bug 720249 is fixed.

(1) https://support.mozillamessaging.com/en-US/kb/keyboard-shortcuts/revision/5614
Blocks: tbkbd-doc-tracker

    
  
Summary: Keyboard shortcut Ctrl+F conflict and cmd_find ambiguity, used for both Find in This Message and Quick Filter → Keyboard shortcut Ctrl+F conflict and cmd_find ambiguity, used for both Find in This Message and Quick Filter: Implement Ctrl+Shift+K for QFB

    
  
Summary: Keyboard shortcut Ctrl+F conflict and cmd_find ambiguity, used for both Find in This Message and Quick Filter: Implement Ctrl+Shift+K for QFB → Keyboard shortcut Ctrl+F conflict and cmd_find ambiguity, used for both Find in This Message and Quick Filter (now Ctrl+Shift+K for QFB)

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: