Open Bug 515081 Opened 13 years ago Updated 7 years ago
Make Ctrl+F shortcut focus search field and Ctrl+Shift+F invoke Search Addresses
While working on documenting search focus shortcuts I noticed that the Address Book (main window) falls out of line regarding search keys (see bug 509338 comment 16). The attached patch makes it so that Ctrl+F (currently: Ctrl+K) focuses the search field there and Ctrl+Shift+F (currently: nothing) invokes the Search Addresses window. This should better fit what we have elsewhere (e.g. the Bookmark Manager), especially since the normal Find In Page doesn't apply here.
Comment on attachment 399106 [details] [diff] [review] proposed patch > <!-- Tasks Menu --> >+<!ENTITY searchAddressesCmd.key "f"> [Looks lonely here. What should Accel+Shift+F do in the mail window?] >- <key key="&focusSearchInput.key;" Nit: remove the comment in messenger.dtd
Attachment #399106 - Flags: superreview?(neil) → superreview+
(In reply to comment #1) > (From update of attachment 399106 [details] [diff] [review]) > > <!-- Tasks Menu --> > >+<!ENTITY searchAddressesCmd.key "f"> > [Looks lonely here. What should Accel+Shift+F do in the mail window?] You know, MailNews shortcuts are kind of scarce (cf. bug 514512). I think we really shouldn't bind something as precious as Ctrl+Shift+F to something like Search Addresses which is second order functionality in the main mail window (who bound Search Messages to Ctrl+Shift+S BTW?!), even if it's currently unused. I'll let Karsten decide, though.
Comment on attachment 400087 [details] [diff] [review] patch v1a It took quite an effort to make all search boxes adhere to the ^K key, we won't drop that. On the up side, this lets you use ^F for "Search Addresses" in the Address Book. > <!-- Search field --> >- <key key="&focusSearchInput.key;" >+ <key key="&searchNameAndEmail.key;" Nope. >+ <key id="key_searchAddresses" >+ key="&searchAddressesCmd.key;" >+ modifiers="accel,shift" Just accel. >+ <menuitem label="&searchAddressesCmd.label;" > accesskey="&searchAddressesCmd.accesskey;" >- id="menu_search_addresses" >+ id="menu_search_addresses" >+ key="key_searchAddresses" > oncommand="onAdvancedAbSearch();"/> Make id the first attribute.
Attachment #400087 - Flags: review?(mnyromyr) → review-
(In reply to comment #3) > (From update of attachment 400087 [details] [diff] [review]) > It took quite an effort to make all search boxes adhere to the ^K key, we won't > drop that. On the up side, this lets you use ^F for "Search Addresses" in the > Address Book. Will you please note in the log that this action is being taken over my explicit objection... You may be right concerning MailNews but on a global scale... well, I already defined my position in comment 0.
(In reply to comment #4) > Will you please note in the log that this action is being taken over my > explicit objection... You may be right concerning MailNews but on a global > scale... well, I already defined my position in comment 0. On a global scale, where is ^F used to focus an already visible search box? If you hit ^F in mailnews, a new find dialog appears. If you hit ^F in the browser, a new find dialog appears. If you hit ^F in view source, a new find dialog appears. If you hit ^F in the composer, a new find/replace dialog appears. If you hit ^F in the mail editor, a new find/replace dialog appears. The only exceptions on window level are Bookmarks and History, and I see their behaviour as a severe violation of the user expectation "^F opens a find dialog"! At least the password dialog uses ^F to focus the search field, so we have a very inhomogeneous situation here. Let's try to find ;-) a common path of action here first -> adding some folks.
Find _dialogs_ ought to die. Practically everywhere. Sometimes (like in mailnews) it might make sense to keep them for _really_ advanced capabilities (though some variant of gloda faced search might also make it mostly useless even in mailnews), but the default find should always be inside the window and not with an additional dialog. Where we have dialogs for simple find, it's remnants of an old time where we were too dumb to make reasonable UI. And it's completely non-intuitive (to not use bad words) to use ^K for search at all, as "K" doesn't have anything at all to do with "find" or "search".
(In reply to comment #2) > (who bound Search Messages to Ctrl+Shift+S BTW?!) Ctrl+Shift+F was reserved on older GTK2 versions no longer supported by 1.9, would you like to swap browser/mailnews/addressbook over now that it's free? I'm not convinced that opening a search window deserves an "easy" key though.
I'm not biased insofar as the actual key combination is concerned, my main point is consistency. Yes, ^K is rather unintuitive, ^F is much more better for something named "Find" (especially since ^S for "Search" is not possible). The current problem is just that some ^F open a new dialog, while some ^F focus another element: "I hit ^F, but nothing opened!"
Comment on attachment 400351 [details] [diff] [review] patch v2 >+ modifiers="accel" So, what we have fairly consistently currently is that Ctrl+K is for quicK search, while Ctrl+F is for text Find, and then we're not sure whether to use Ctrl+Shift+S or Ctrl+Shift+F for advanced Find. I still would like to see both keys used in the 3pane, one for Search Messages and one for Search Addresses, in which case the Search Addresses key would also be used for the address book, but I could live with having one key in the 3pane and then consistently using the same key in address book, bookmarks and browser (in followup bugs).
jftr, Cmd+Shift+F is now used in browser for toggling full screen mode on mac
Assignee: jh → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.