Closed
Bug 684715
Opened 14 years ago
Closed 14 years ago
Search UI inconsistency across the tabs
Categories
(Thunderbird :: Search, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 564328
People
(Reporter: extigmata29, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
Build ID: 20110830092941
Steps to reproduce:
1) I tried to use keyboard shortcut Ctrl-F
2) I tried to use already open Quick Filter on other than first message list tab
[windows 7 pro 64, TB 6]
Actual results:
1) Quick search (Ctrl-F) is inconsistent. In a first tab the shortcut opens Quick Filter and it works well. However, in any other tab the same shortcut opens not Quick Filter but Message Body Find at the bottom of the message.
2) Additionally, if Quick Filter is already open, it does not work for any tab but the first one.
Expected results:
1) Ctrl-F should always process the same in all message list tabs: open and use Quick Filter
2) Quick Filter should work for all the message list tabs, not only for the first one
Comment 1•14 years ago
|
||
(In reply to extigmata29 from comment #0)
> 1) Quick search (Ctrl-F) is inconsistent. In a first tab the shortcut opens
> Quick Filter and it works well. However, in any other tab the same shortcut
> opens not Quick Filter but Message Body Find at the bottom of the message.
This is a design choice and IMHO it's fine; in the main view you create a filter, but in an additional tab showing a message, you usually press Ctrl-F to find a keyword.
> 2) Additionally, if Quick Filter is already open, it does not work for any
> tab but the first one.
When I press Ctrl-F it works in the current tab/view
You can try this extension (personally I didn't try it) https://addons.mozilla.org/en-US/thunderbird/addon/functions-for-keyconfig-thunde/
Also, post your question here and you might get some advice: http://groups.google.com/group/mozilla.support.thunderbird/topics?pli=1
My Thunderbird:
Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
Build ID: 20110902163914
Comment 2•14 years ago
|
||
extigmata29, thank you for your feedback. You are right, the behaviour of Ctrl+F is not easy and may appear inconsistent in TB up to version 7. The good news is, starting from version 8, the complexity of "magic" Ctrl+F has been disentangled (bug 564328) and we'll have a completely consistent behaviour:
Ctrl+Shift+K for the quickfilter always (where applicable) and
Ctrl+F for the message body filter always (where applicable).
(In reply to extigmata29 from comment #0)
> Actual results:
> 1) Quick search (Ctrl-F) is inconsistent. In a first tab the shortcut opens
> Quick Filter and it works well. However, in any other tab the same shortcut
> opens not Quick Filter but Message Body Find at the bottom of the message.
> 2) Additionally, if Quick Filter is already open, it does not work for any
> tab but the first one.
It's not about first vs. other tabs, it's about how often you press Ctrl+F. Up to TB version 7, first Ctrl+F will bring up quickfilter bar (qfb) and (with focus in qfb), second Ctrl+F will bring up body search (and under certain circumstances, the magic doesn't work). Of course in whichever version, you won't get qfb if there are no message lists, and you'll not get body search if there is no msg body on the tab.
> Expected results:
> 1) Ctrl-F should always process the same in all message list tabs: open and
> use Quick Filter
Yes, bug 564328 implements Ctrl+Shift+K which will work consistently in all message list tabs to open qfb, starting from v8
> 2) Quick Filter should work for all the message list tabs, not only for the
> first one
worksforme, see above.
extigmata29, since the problems you mention have been fixed for upcoming version 8 of TB, I'll close this as a duplicate of bug 564328.
Feel free to comment if you think there's something which still needs attention.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
OS: Windows 7 → All
Hardware: x86_64 → All
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•