Closed Bug 587478 Opened 10 years ago Closed 6 years ago
More intuitive way to close the Quick Filter Toolbar
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20100701 SeaMonkey/2.0.6 Build Identifier: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20100802 Thunderbird/3.1.2 Opening the Quick Filter Toolbar is easy on a PC. Just select Ctrl-F. Closing the toolbar, however, requires going to the menu bar and selecting [View > Toolbars > Quick Filter Bar]. Please either provide an X button on the Quick Filter Toolbar to close it or else make Ctrl-F a toggle that can both open and close the toolbar. I suspect a button would be a more universal implementation not specific to PCs. However, there already is an X button within the search input box for clearing that box. Reproducible: Always I'm also curious as to why this toolbar is called Quick Filter. It does not seem to be related to filtering as processed by going to the menu bar and selecting [Tools > Message Filters]. This toolbar is only used for searching.
> Closing the toolbar, however, requires going to the menu bar and selecting No, you have a keyboard shortcut here as well, just hit the ESC key twice. The ambiguity of the keyboard shortcuts between quick-filter bar and the find in message function is handled in bug 564328. I think that I've seen a request to add an explicit "Close" button [x] within the quick-filter bar itself already, but can't find it right now. If you have the tab bar visible, there is also a handle on its right-hand side to toggle the visibility of the quick filter bar.
Does not the Esc key have too many unrelated uses? I know it can be used as a replacement for the non-functional Stop button, to stop attempts to connect to a server or to download messages.
Yes, it's getting more and more difficult to find new keyboard shortcuts, where ESC is probably still ok (simply means "end whatever you are doing right now"). The Ctrl+F shortcut is trickier to interpret as it "opens" a new function.
Component: Toolbars and Tabs → Search
OS: Windows XP → All
QA Contact: toolbars-tabs → search
Hardware: x86 → All
Version: unspecified → Trunk
Summary: Closing Quick Filter Toolbar → More intuitive way to close the Quick Filter Toolbar
(In reply to comment #2) > Does not the Esc key have too many unrelated uses? I know it can be used as a > replacement for the non-functional Stop button, to stop attempts to connect to > a server or to download messages. I am certain I this mentioned in bugzilla or getsatifaction, that implementing escape to close the quick filter bar had usurped cancellation of message download. But I find no such bug report. Does anyone recall stop doing this, or seeing this report? But there is * bug 478916 - can't escape or cancel server query, have to wait for time out (should stop even when connecting or looking up server) * Bug 583133 - Stop button should not collapse/hide quick filter bar
(In reply to comment #4) > I am certain I this mentioned in bugzilla or getsatifaction, that implementing > escape to close the quick filter bar had usurped cancellation of message > download. But I find no such bug report. > [...] > Does anyone recall stop doing this, or seeing this report? > [...] How about: Bug 120795- When pop is unreachable, Esc doesn't work Bug 239616 - "stop" button should cease attempt to connect to mail server
This bug is not actionable. Description in comment 0 is outdated (e.g., we now have Ctrl+Shift+K for qfb), and does not have required format. Please provide new description with separate sections for - Steps to reproduce - Actual result - Expected result Then, add a link to the new STR in whiteboard. Also, I think comment 4 is worth investigating: Has ESC for QuickFilter usurped cancellation of message download with ESC (as a shortcut for Stop Button)? If yes, do we have a bug for that?
Yes, Ctrl-Shift-K now launches the Quick Filter Toolbar instead of Ctrl-F. The rest of the Description remains correct. Without numbering the steps, you can see from the Description how to create the situation. You can also see what actually happens (nothing, because there is no button to close) and what is expected. What is "STR". Yes, Esc still closes the Quick Filter Toolbar. Whether a single use of Esc also stops loading a new message at the same time, I do not know.
Apart from ESC for keyboard users, we now have Quick Filter toggle button for mouse users, so description is even more inadequate than before, and this RFE becomes a little less relevant again (although it might still have a point, I'm not against it if we can find a reasonable design). (In reply to David E. Ross from comment #7) > Yes, Ctrl-Shift-K now launches the Quick Filter Toolbar instead of Ctrl-F. > The rest of the Description remains correct. Without numbering the steps, > you can see from the Description how to create the situation. You can also > see what actually happens (nothing, because there is no button to close) and > what is expected. David, I think you know that I generally appreciate your contributions. However, from many years of bmo triaging experience, trust me that bugs without a crystal clear description have very little chance of ever getting attention (getting attention is hard enough for clear bugs...). This bug isn't actionable because you do not follow clear separation of 1) Detailed steps to reproduce = STR (and yes, they should be numbered steps to ensure every detail is captured correctly, which is not the case in comment 0) 2) actual result 3) expected result All of these ideally as concise as possible, but as detailed as required. It's not about nitpicking or enforcing red tape, it's about getting a clear, objective, and verifiable analysis of the problem. Even if all the relevant aspects were correctly hidden somewhere in your comment 0 (which they aren't), nobody has time to waste on interpreting and dissecting the description. Vagely understanding that you want an [x] button on the qfb doesn't help much. We need to know exactly what steps you take, why they don't work for you, and what exactly you'd expect instead. Doing so would also uncover the important fact that this RFE only applies to mouse-only users, which is not even explicitly mentioned anywhere. (For keyboard users or "mixed", we're definitely fine here). So this bug is currently incomplete -> resolving accordingly. Sorry but as I'm one of the few who actually look into these bug reports... Feel free to reopen if someone provides an updated, concise and rule-conforming description. Btw you've already stated one problem namely that your proposal would result in two [x] buttons on the right side of qfb (one for search input and one for the bar), which would certainly be odd and error-prone. What then? > What is "STR". Steps to reproduce.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.