Quickfilter: "Filter messages by" selectors should be available *before* filtering (Sender, Recipients, Subject, Body)

NEW
Unassigned

Status

Thunderbird
Search
--
enhancement
6 years ago
3 years ago

People

(Reporter: Derek Williams, Unassigned)

Tracking

(Blocks: 1 bug, {uiwanted})

Trunk
uiwanted

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [has 2 UI proposals in bug 570815, Attachment 460747], URL)

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
Created attachment 657981 [details]
Screen Shot 2012-09-04 at 03.34.23.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20120828083259

Steps to reproduce:

I wanted to filter messages in the messages list, and I wished to change the settings I had from 'Sender', 'Recipients', 'Subject', to 'Body'.


Actual results:

These field names were not visible so as to be selectable unless I first typed something into the search field.


Expected results:

The Filter Messages by field names should be visible even when the field is empty.
(Reporter)

Comment 1

6 years ago
Created attachment 657982 [details]
Existing selection only shows up when at least one character is entered
(Reporter)

Comment 2

6 years ago
Created attachment 657983 [details]
filter changed to 'Body'
Hi Derek,

The current behaviour is by design, probably introduced by Bug 545955 (or perhaps even before that). Which makes your bug a RFE -> enhancement.

We've seen this idea before, you're not alone :) TB2 used to offer pre-selection of filter selectors. I don't specifically recall a lot of requests to re-introduce that (although there were a lot of complaints against quick filter bar when it was introduced). While this is a nice idea, it's probably not a pressing issue.

Attachment 460747 [details] of bug 570815 has a live demo with 2 variants of preselecting selectors, as requested in this RFE:
1) floating selector bar when qfb search field has focus
2) tb2-style drop-down menu

Another approach: Bug 538821 (gmail-style expressions)

We have a number of bugs suggesting improvements to quick filter & global search, even to combine them (bug 667246, bug 526221, bug 570815).

BMO Quick Search for bugs relating to QuickFilter Bar:
:thun,mail su:quick su:filter,search
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athun%2Cmail%20su%3Aquick%20su%3Afilter%2Csearch;list_id=4270135

From above search, no duplicates found.
IMO, this is a nice idea that should be confirmed. Objections, anybody?

I wonder if we could just show secondary quick filter selectors bar as soon as quick filter search box has focus, but I'm not sure how that interacts with those other quick filters (unread, starred, known contacts, attachments) that don't require secondary selectors. Derek, most of the filters on the left don't require secondary selectors. Users of these would be annoyed to see the secondary selector bar all the time if they don't need it. Any ideas how to avoid that?

Alternatively, we could show the secondary selector bar when user clicks on some icon for that purpose, e.g. the magnifier (perhaps with an added dropdown overlay), which currently does nothing.
Severity: normal → enhancement
Keywords: uiwanted
OS: Mac OS X → All
Hardware: x86 → All
Summary: "Filter messages by" filter names vanish when search field empties → Quickfilter: "Filter messages by" selectors should be available *before* filtering (Sender, Recipients, Subject, Body)
Version: 15 → Trunk
(Reporter)

Comment 4

6 years ago
Thank you Thomas

I think your idea to bring up the selections as soon as the Filter These Messages field has focus (both by clicking inside it and by the shortcut +shift+K) would solve the problem perfectly, because it would keep free the filters screen real estate until the exact point where the filters were actually required, and would relinquish it as soon as escaped from.
Component: General → Search
(Reporter)

Updated

5 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
Hey Derek, we don't usually wontfix bugs without giving reasons, and per comment 3 to which you agreed in comment 4, this looks like a worthwhile idea although it may not be a matter of priority. We even have first UI proposals in the live demo of 
Attachment 460747 [details]. Bug 570815 does not necessarily include your RFE (although it's the preferred solution there), so this is not a dupe and I'd rather keep this open; perhaps somebody feels like clarifying the UI or even working on this. When that may or may not happen is another question, so don't expect this to be moving too soon unless you bring your own coder...
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Blocks: 570815
Status: REOPENED → NEW
Whiteboard: [has 2 UI proposals in bug 570815, Attachment 460747]

Comment 6

4 years ago
This is something that has annoyed me from the outset, and I would very much like to see the buttons stay visible all the time (perhaps just with a pin) in the shorter term until the more permanent fix is put in place.  The reason is that TB slows to a crawl if you had "Body" selected last time and start to type in the box again before being able to narrow down the search with more characters.  Actually, it also annoys me that it starts searching before pressing enter or the magnifying glass, but that's another story.
So +1 from me for a fix for this.
You need to log in before you can comment on or make changes to this bug.