Closed Bug 545955 (filterbar) Opened 14 years ago Closed 14 years ago

quick search filtering outside of full searching (implement filter bar, separate quickfilter and global search)

Categories

(Thunderbird :: Search, defect)

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

Tracking

(blocking-thunderbird3.1 beta2+, thunderbird3.1 beta2-fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 3.1b2
Tracking Flags:
Tracking Status
blocking-thunderbird3.1 --- beta2+
thunderbird3.1 --- beta2-fixed

People

(Reporter: clarkbw, Assigned: asuth)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

(Keywords: late-l10n)

Attachments

(5 files, 6 obsolete files)

Screenshot of Lanikai with proto filter bar 0.7
70.52 KB, image/png
Details
testcase for bug in comment #42
1.57 KB, text/plain
Details
Screenshot of bad filtering
168.17 KB, image/png
Details
Screenshot of tab-bar buttons
2.63 KB, image/png
Details
v6 with aero now!
311.48 KB, patch
asuth
: review+
asuth
: ui-review+
Details | Diff | Splinter Review 
The quick search is a fast and easy way to filter down the results of the current view.  Currently this search is a bit hidden under the full search system and so people are having a hard time finding it and using it.  This bug is about separating out the two searches.

Here's a separate filter input for quick search which acts like a notification bar appearing above the thread list.

+-------------------------------------------------------+
| (get) (write) (ab) (tag|v)  [_Search all messages__]  |
+-------------------------------------------------------+
| Inbox    \                                            |
+-------------------------------------------------------+
| / folders / |                  [ Filter Messages ] (x)|
|             |-----------------------------------------+
|             |                                         |
|             |                                         |
|             |                                         |
|             |-----------------------------------------|
|             |                                         |
|             |                                         |
|             |                                         |
|             |                                         |
|             |                                         |
|             |                                         |
|             |                                         |
|             |                                         |
|             |                                         |
+-------------------------------------------------------+

== Introduction ==
In order to introduce the notification bar we'll likely need to show it initially so people see it.

If we allow people to close the notification bar we will have to teach them how to bring it back (something we don't have a button for right now). Minimally we can create a new menu item in the Edit menu for "Filter Messages" which brings up the filter bar.

== Facets ==

The current quick search allows changing facets by choosing which possible grouping of the options available "Subject", "Sender", "Recipients" you want to filter over. This is a bit cumbersome because of the persistence of the filter type and the need to choose a new type each time before filtering.

[v Filter Messages ]

We could possibly improve this situation by displaying the filtering options as people focus the area.

e.g.

[ Filter Messages ]_____________________
| [x] Subject [x] Sender [x] Recipients |
----------------------------------------+

On focus of the filter input we popup a set of options for changing the filtering method.  This allows us to persist the options people were using yet also notify people of the current options being applied.

I have some more notes I'll try to add later and andrew has a scaffolding extension http://hg.mozilla.org/users/bugmail_asutherland.org/proto-messagefilterbar/
Whiteboard: [UXprio]
Since this is going to have strings, we'll want this for beta2.  Targetting at that.
blocking-thunderbird3.1: needed → beta2+
will it also make sense to have view and folder picker in the same area?  
I've always seen them as being related.
Blocks: 552576
Whiteboard: [UXprio] → [UXprio][in-progress work with clarkbw]
Sounds like a cool plan, though perhaps some of us will need to get used to the split box.

(In reply to comment #0)
> [ Filter Messages ]_____________________
> | [x] Subject [x] Sender [x] Recipients |
> ----------------------------------------+

What about "Message text/full text/msg body text", which currently forms part of filter options? Shouldn't this be sth like this?:

[ Filter Messages ]_______________________________________
| [x] Subject [x] Sender [x] Recipients [x] Message body  |
----------------------------------------------------------+

(in the long run, can we replace current filter technology with gloda-based filter?)
Body already is in the prototype; the ASCII artist will be dealt with.

In the log run, yes, current filter technology will be replaced with gloda-based technology.
(In reply to comment #4)
> Body already is in the prototype; the ASCII artist will be dealt with.
:))
> In the log run, yes, current filter technology will be replaced with
> gloda-based technology.
:))

Andrew, the prototype is pretty cool! (Not that I'm signed for the idea of splitting filter and search yet, but I'll play with it and see how it feels)

Some questions/thoughts

1 What's the purpose of the "No results" caption before the box?
1b When there's no results for a word filter, how about red background as we do in message body's find bar? Would be a good visual indication and warning that there's an active filter that's hiding all the messages...

2 After switching off all header search criteria on yellow bar, then removing the filter (yellow bar goes away), then entering a new filter term:
Actual: All filters still switched off, filter has no effect
Expected: In this case, return to default header filter criteria (subj, sender, recipient)

2b Likewise, with all header criteria switched off (no word filtering possible), when user deliberately presses enter after filterword, we should switch default header filter criteria back on

2c Should the yellow bar disappear after last header filter (and thus whole word filter) is switched off? That way, we'd be consistent in showing user that when there's yellow bar -> some header filter is active vs. no yellow bar -> no header filter is active. Of course when there's filtered tags, the bar must stay

3 What if I want to set header filter criteria beforehand? (Maybe I can live without, and get used to setting after typing something? Also, we shouldn't show the yellow bar if there's no active filter... so perhaps it's right as it is now)

4 An unreflected feeling tells me I'd want a button to remove an active word filter from yellow bar (but not sure)
(In reply to comment #5)
> Andrew, the prototype is pretty cool! (Not that I'm signed for the idea of
> splitting filter and search yet, but I'll play with it and see how it feels)

Thanks!
 
> 1 What's the purpose of the "No results" caption before the box?

It's not hooked up right now; Bryan put it in to try and help make it easier to figure out what's going on.  I need to hook it up and we'll see how useful it is then.  (The information is available in the status bar too, but most people probably who do not already know that aren't particularly likely to discover it.)

> 1b When there's no results for a word filter, how about red background as we do
> in message body's find bar? Would be a good visual indication and warning that
> there's an active filter that's hiding all the messages...

We've been trying various things with this.  I made the whole bar turn pink and I think Bryan has some styling like this at least on OS X right now where the zebra-striping ends up pink as a more subtle expression of the situation.

> 2 After switching off all header search criteria on yellow bar, then removing
> the filter (yellow bar goes away), then entering a new filter term:
> Actual: All filters still switched off, filter has no effect
> Expected: In this case, return to default header filter criteria (subj, sender,
> recipient)

Yeah, that's odd.  We will probably try making it so you can't actually turn off all the text filter criteria.  Users should clear the text filter box if they want to stop text filtering.  I'm landing some functionality that enables use of the escape key to do that via the keyboard as well.

> 3 What if I want to set header filter criteria beforehand? (Maybe I can live
> without, and get used to setting after typing something? Also, we shouldn't
> show the yellow bar if there's no active filter... so perhaps it's right as it
> is now)

The text filter constraints are going to be sticky so you don't have to keep changing them all the time.
 
> 4 An unreflected feeling tells me I'd want a button to remove an active word
> filter from yellow bar (but not sure)

Hitting the escape key or using the 'clear the search box' icon should accomplish that.
Thx, I see.

Andrew, another often-requested and discussed functionality you might wish to include on your filter bar: optional "sticky filter" for manual cross-folder searches. Maybe just an iconic button with a pin? I've often seen that used to make things stick.

STR: Enter filter terms, no results in first folder, click on different folder
Actual: need to retype filter term for next folder
Expected: provide way (button etc.) of making filter stick across different folders
(In reply to comment #7)
> Andrew, another often-requested and discussed functionality you might wish to
> include on your filter bar: optional "sticky filter" for manual cross-folder
> searches. Maybe just an iconic button with a pin?

I'm intrigued by this idea! Good stuff.
(In reply to comment #7)
> Andrew, another often-requested and discussed functionality you might wish to
> include on your filter bar: optional "sticky filter" for manual cross-folder
> searches. Maybe just an iconic button with a pin? I've often seen that used to
> make things stick.

This has actually been implemented in the current prototype for a few days as available in mercurial (not on AMO), although without an icon.  It's experimental; it might end up being pushed out to be something enabled by an extension.

I'll probably push an updated version of the extension to AMO in the next day or so before we convert the extension into something land-able.  My only reluctance is that there are a lot of speculative/experimental things that I've added that look ugly and I don't want people to think that's how we're going to actually ship it.
I've stumbled across this bug a bit late in the game, but...

What's wrong with the current functionality. With Gloda off I can still use the searchbar to search for messages in a folder (with the proviso I've just posted to m.s.t: searching doesn't work in the first tab, but _does_ work in subsequent tabs)?

Why do we need a _different_ search bar?
(In reply to comment #10)
> Why do we need a _different_ search bar?

Hi John, through some user feedback and study of the original change we've found that many people couldn't find the old quick search options.  Additionally with the quick search hidden below the full search it's much more cumbersome to access it.

The idea of this new quick search bar is to bring back a fast quick (as a different element) and improve the old system with a couple of better interactions compared to the old quick search bar.

If you try out the add-on, I would recommend the latest version from source control, I think you'll see it provides a much better experience.  If you weren't using Gloda for searching over all your messages then the change will really be about better options for quick search instead of having both easier to access.

-

For anyone trying this extension from source I've put a bunch more theme updates in the latest version for both Windows and Mac.  I need to get some testing on Linux but Andreas was going to look most of that for me.  I think we're pretty much ready to push a new version to AMO.
Wow! This rocks! Andrew & Bryan are up to revolutionizing quick filters, excellent stuff. 

- We now have Power Filter (as promoted by me in bug 522985)!!! Please ensure that this revolutionary way of filtering is sufficiently advertised in the relnotes and explained in the help files (cf. sample scenarios from bug 522985)!
- Good ideas don't die: In partial fulfillment of our request in bug 526221, there's now a seamless transition to change a resultless quick filter search into a global search, and the simplicity of the process is just gorgeous:
Type filter terms -> no matches -> press Enter -> global Search on your filter terms. Again, this should be advertised and explained.
- Thanks for implementing "Sticky filter" pin icon as requested by my comment 7. (Comment 7) Pls keep it!
- The overall styling has been greatly improved, this now feels like a natural part of the application.

***** Some more comments/wishes/nits: *****

* Filter bar is a toolbar. As such... *

a) ...should be listed under View > Toolbars > Filter bar (toggle on/off)

b) (long-term) ...should be fully customizable (different people have different needs)
- need icon-only mode (icon text will never be readable for many people anyway, and two letters with dots really don't help much)
- in the long run: customize which buttons I want; perhaps add way of adding buttons that filter for a specific tag

* More Menu integration *

c) Add new menu: Edit > Find > "Filter these messages   Ctrl+F" (cf. e)
Adding this menu is especially important to somewhat reveal "Ctrl+F toggle magic". Is there a way we could mirror that magic in the shortcut labels, perhaps Ctrl+FF for "Find in this message?" However, Ctrl+FF will only work when you don't happen to be in the filter bar already.

d) Add new menu: Edit > Find > "Search all messages     Ctrl+Q" (cf. e)
While we're at it, let's include another important find operation to the menu.

e) Proposed sequence for Edit > Find menu

*Search all messages...   Ctrl+Q*
*Filter these messages... Ctrl+F*
Search messages...        Ctrl+Shift+F
Search addresses...       
---------------------------------------
Find in this message...   Ctrl+F
Find again                Ctrl+G

I moved "Find in this message" to bottom because
- Filtering/Searching are presumedly more important/frequent actions
- Due to "Ctrl+F toggle magic", you actually HAVE to "filter these messages" before you can "find in this message" (press Ctrl+F twice). So filter is always the first action, as mirrored in the menu sequence.
"Search all messages" should be at the top (most global search, topmost in the UI, too)

* Layout/Strings *

f) "Filter these messages... <control-f>" should be "Filter these messages <Ctrl+F>", for consistency with shortcut labels in menus and better readability. I don't mind the dots, but it should be consistent with global search: either dots for both or not. Although dots usually indicate that you'll get a dialogue when you click, and they don't add any value here.

g) Add tooltip to filter bar tab-button:
"Show filter bar" when hidden and "Hide filter bar" when shown.
Alternatively, more action-oriented:
"Filter these messages" and "Hide filter bar".
For the latter, perhaps "Remove filter and hide filter bar".

h) Tooltip "There are no matches..."
- IMO it's really odd when it's huge. It's really jumping at me for no reason, more like a virus alert. Perhaps it shouldn't be bound to the height of messsage pane. Certainly, it should NOT overlap the splitter (very odd). I'd think this might look better:
- Probably Tooltip should never be bigger than the text it shows. A three-lines tooltip is still big, and easy to spot on a blank background when there are no matching messages. 

* Behaviour/Functionality *

i) There's a problem where the "There are no matches..." tooltip stays on top while new matches are already showing up below the tooltip after user has changed criteria!

STR:
0) have a big folder with some msgs that have "foo" in the body, but NOT in Sender, Recipients, or Subject
2) filter for "foo" (on Sender, Recipients, Subject) -> no matches tooltip (correct).
3) on the bottom filter criteria bar, switch on "Body" button

Actual result
- "No matches..." tooltip stays on top all along (bug) while
- matching messages are correctly showing up under the tooltip
So the tooltip still claims "No matches" while matches are already showing up underneath.

Expected result
- as soon as there's a single match, ensure that "No matches..." tooltip goes away immediately


j) Problem when user switches off all criteria and then re-confirms (ENTER), re-types or changes the filter term

(In reply to comment 6)
> Yeah, that's odd.  We will probably try making it so you can't actually turn
> off all the text filter criteria.  Users should clear the text filter box if
> they want to stop text filtering.

You'll create unnecessary workflow problems if you prevent users from turning off all text filter criteria. STR:
- User wants to switch from "Sender, Recipients, Subject" to "Body"
- Intuitive clicks are: switch off Sender, Recipients, Subject (in that order), then switch on "Body".
- NOT intuitive: switch off Sender and Recipients; fail on switching off Subject; switch on Body; then switch off Subject. Sorry, but that's way too hard for anyone to figure out.

Instead, I propose this:

STR
1) add filter words
2) switch off all text filter criteria (filter words still present, but filter has no effect)
3a) re-confirm the existing filter term with ENTER
3b) modify existing filter term (delete letters, add letters)
3c) remove existing filter term (ESC) AND enter new filter term

Actual result
- all text filter criteria buttons are turned off, so we ("correctly") don't filter anything

Expected result
3a)b)c) in all of these cases, it's obvious user wants to carry on with some filtering. But he forgot to switch on some filter criteria (which implies he doesn't care much about the criteria, and just wants to carry on with some filtering).
-> We can help the user in this situation by turning the default filter criteria back on, and just go ahead with filtering as expected by the user.
-> Technically, we should turn on default criteria (Sender, Recipients, Subject)
- when all text filters are off AND
- filter term changes (or is removed) OR
- user presses ENTER after existing filter term

Keep up the excellent work.
Alias: filterbar
Summary: quick search filtering outside of full searching → quick search filtering outside of full searching (implement filter bar, separate quickfilter and global search)
A bug in the "Sticky Filter" - no results upon switching folders, but there should be some

STR
1 have folder1 (inbox) with tagged and non-tagged msgs
2 On filter bar, switch ON tag filter button
-> matching tagged msgs are filtered out (ok)
3 On filter bar, switch ON "sticky filter" pin icon
4 Click on folder2 (sent) without matching messages (no tagged messages)
-> "No matches" tooltip (ok)
btw, it should be "There are no *matching messages*..." (not just "matches")
5 Return/click on folder1

Actual result
- there are no matches (message pane and preview pane are blank)

Expected
- matching msgs should be shown (as after step 2)
Bug: When you have more than, say, 8 tags, or one very long tag, the text filter criteria on the bottom bar are pushed off the screen to the right.
Generally speaking, the current implementation of the tag filter criteria on the bottom bar is unscalable, not just because of a missing scrolling device, but in principle. Say you have 30 tags, does it make sense to show them all in a row, but you can see only 6 at a time? Then if you filter for some of these, say "Important, c-tag, y-tag, z-tag" by pushing them down (pressed), you might see none of those pressed buttons depending on where in the sequence they are. I think what we need here is something that takes Firefox's tag application system from the bookmark star's panel as a model, with a text input field to enter tags that you want to filter for, and an additional popup dialogue with a list of all tags where you can alternatively /check/ those you want to filter for. In other words, instead of reinforcing the current problem that tag's aren't scalable enough, we should try and make them scalable along the idea of bug 370076. Which is most certainly another instance of "Good ideas don't die". Unfortunately, it's also "Good ideas are sometimes hard to implement"... :)
Well, I downloaded, built and installed the extension...I don't know if I'm being stupid or what, but the filtering doesn't work for me at all.

I type in the filter box and nothing happens in the message list pane.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b1 Thunderbird/3.0.3

Running on Fedora 12 x86_64.
(In reply to comment #16)
> Well, I downloaded, built and installed the extension...I don't know if I'm
> being stupid or what, but the filtering doesn't work for me at all.
> 
> I type in the filter box and nothing happens in the message list pane.

Look into Tools -> Error console , do you have a error message on the second line bout component.import not declared or something like that ?
The build script didn't know about the modules directory; I've fixed this.
Also, if you're going through the effort of checking out the source code, you probably want to do the 'virtual symlink' method of installation instead of building the XPI and actually installing it.  That way when we change something a simple "hg pull -u" has you using the latest version on next restart rather than having to laboriously build the xpi, install it, etc.

This consists of creating a file called "messagefilterbar@mozillamessaging.com" in your extensions directory where the contents of that file are the path to the root dir of the message filter bar hg checkout.
(In reply to comment #19)
> This consists of creating a file called "messagefilterbar@mozillamessaging.com"
> in your extensions directory where the contents of that file are the path to
> the root dir of the message filter bar hg checkout.

extensions directory in your profile directory that is.
Error: uncaught exception: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: chrome://messagefilterbar/content/messageFilterBar.js :: <TOP_LEVEL> :: line 41"  data: no]

What do I do to fix this?

I didn't do the 'symlink' thing because I only downloaded a tarball from Git.
asuth's latest patch doesn't provide a working .xpi it seems. The xpi seems to be lacking the appropriate directory structure...

Archive:  messagefilterbar.xpi
 Length   Method    Size  Ratio   Date   Time   CRC-32    Name
--------  ------  ------- -----   ----   ----   ------    ----
       0  Stored        0   0%  03-29-10 12:21  00000000  chrome/
   55967  Defl:N    18095  68%  03-29-10 12:21  58e3e275  chrome/messagefilterbar.jar
     678  Defl:N      235  65%  03-29-10 12:21  464a00f9  chrome.manifest
       0  Stored        0   0%  03-29-10 12:21  00000000  defaults/
     851  Defl:N      427  50%  03-29-10 12:21  0c686a72  install.rdf
     199  Defl:N      132  34%  03-29-10 12:21  875ec7bb  messagefilterbar.js
   39297  Defl:N    11153  72%  03-29-10 12:21  45dd4fe0  messageFilterManager.js
       0  Stored        0   0%  03-29-10 12:21  00000000  modules/
--------          -------  ---                            -------
   96992            30042  69%                            8 files
OK, I've got the extension working now, and it is quite nice. It's certainly easier to do different types of searches than the old way

I still find there's a real chance of user confusion with the 2 different (quick) search interfaces though.
(In reply to comment #22)
> asuth's latest patch doesn't provide a working .xpi it seems. The xpi seems to
> be lacking the appropriate directory structure...

Thanks for pointing this out; it turns out an earlier attempt to make the build script work on OS X did not go so well.  Apparently the --parents flag of GNU cp is a GNUism.  I've backed out the offending changeset.
Whiteboard: [UXprio][in-progress work with clarkbw] → [clarkbw working UX will push new extension, asuth has mozmill tests in progress][UXprio]
With the Message Filter Bar prototype installed the buttons in the toolbar are missing the disabled="true" tag. You can test this by selecting an account (not a folder), then the buttons like "Tag" or "Back" or "Forward" are not inactive. When this extension is deactivated the buttons are inactive. I've tested this on TB 3.0 and Shredder.
(In reply to comment #25)
> With the Message Filter Bar prototype installed the buttons in the toolbar are
> missing the disabled="true" tag. You can test this by selecting an account (not
> a folder), then the buttons like "Tag" or "Back" or "Forward" are not inactive.
> When this extension is deactivated the buttons are inactive. I've tested this
> on TB 3.0 and Shredder.

Good catch and thanks!  I've just pushed a fix.

The code that vectored the command handling code so we could hook into control-f had a silly typo in it.  (It's throw-away code that will be discarded when we land the extension into core so it didn't get a lot of attention.)
This is very cool, I've tested version 0.3 yesterday. And I really like it.

Things I've noticed (on OS X 10.6 with TB 3.2a):
1. The big yellow tooltip you see on the left side if you have no search results is very aggressive. I have this tooltip everytime in the foreground. If I switch to Finder, iTunes or any other app, the tooltip is still in the foreground.

2. I'am right, that at the moment the plugin isn't easy to localize? I've tried to localize it, but it seems messagefilterbar.dtd and messagefilterbar.properties doesn't contain the strings from the UI and you have to edit it directly in messageFilterBar.xul, right?

3. Nit: I think the pink strips, you see if you have no search results, are not very cool. :-D
Really slick. But there are some issues with the way it works with my use case. I use tags typically to show things that I don't want to see anymore, because they have been filed away or marked as part of some group of specialized messages (like bugzilla). So frequently I am searching for messages that DON'T contain a particular tag. I see no easy way to do this.

You might be able to do that by setting the tag part so that, if you click an enabled tag, the search changes to NOT having that tag (slash though it or something). Then click again to remove.

Similarly, there is no way for the tag bar to show messages that are untagged, other than all messages. The way that I would like to use tags is to start showing everything, then remove specific tags. I can't do that with the bar as written. I also think that a fairly common use of tags would be to want at least one tag on every message, so the ability to show messages without tags is important.

Short version: the tagging currently assumes that tags are things that you want to see. You really have not considered the ramifications of a tag usage style where tags mean things that you don't want to see, and untagged is significant.
(In reply to comment #28)
> This is very cool, I've tested version 0.3 yesterday. And I really like it.
> 
> Things I've noticed (on OS X 10.6 with TB 3.2a):
> 1. The big yellow tooltip you see on the left side if you have no search
> results is very aggressive. I have this tooltip everytime in the foreground. If
> I switch to Finder, iTunes or any other app, the tooltip is still in the
> foreground.

This should be fixed in the next, next version.  Asuth is working on it so it will go away when you're in another app.

> 2. I'am right, that at the moment the plugin isn't easy to localize? I've tried
> to localize it, but it seems messagefilterbar.dtd and
> messagefilterbar.properties doesn't contain the strings from the UI and you
> have to edit it directly in messageFilterBar.xul, right?

True, some of the strings are hard coded.  If you have a chance to fix that up we'd love a patch.

> 3. Nit: I think the pink strips, you see if you have no search results, are not
> very cool. :-D

Heh, not too hip.  I'm thinking of removing it.  Any ideas for how to relate that the tree is empty because your quick search filters are too strict?
(In reply to comment #30)
> (In reply to comment #28)
> > 2. I'am right, that at the moment the plugin isn't easy to localize? I've tried
> > to localize it, but it seems messagefilterbar.dtd and
> > messagefilterbar.properties doesn't contain the strings from the UI and you
> > have to edit it directly in messageFilterBar.xul, right?
> 
> True, some of the strings are hard coded.  If you have a chance to fix that up
> we'd love a patch.

Yes, I have a patch that makes anything localizable (anything I found), except the red "no results", because I couldn't find it in messageFilterBar.xul
I've tried the patch for "en-US" and "de".
(In reply to comment #31)
> Yes, I have a patch that makes anything localizable (anything I found), except
> the red "no results", because I couldn't find it in messageFilterBar.xul
> I've tried the patch for "en-US" and "de".

The results widget builds a string dynamically in messageFilterManager.js towards the bottom.  I guess it can get its string bits from attributes set on its DOM node so we can keep everything in a DTD.  2 entities would be required; one for "No results" and a pluralization-logic compatible one for "# messages".

If you could post the patch on this bug that would be great.  Extra super useful would be if the patch includes localization comments... :)
I just checked out the add-on version 0.6, here are my comments:

1.
toolbar button label logic doesn't work well with switching layouts (Classic/Vertical). It seems to react to window size, but not thread pane width. For me the button labels didn't collapse, shoving the thread pane splitter to the right, leaving a "4cm" message pane.

2.
"Contact" filtering. First I thought it didn't do anything at all. Then I found out it filters according to the "Personal Address Book". But if I "star" contacts, they don't even go there, but into "Collected Addresses". And my "Mac OS X Address Book" is completely ignored. I'd hope interaction between these Thunderbird features can be improved before the integration...
This is my patch for making the messageFilterBar.xul localizable. Tested for "en-US" and "de". I think most of the entity names are self-explanatory, so there is only one comment. But note, this is my first l10n patch. And it doesn't respect the two missing attributs in messageFilterManager.js, because at the moment I have no idea how to handle this (but maybe I will find out how this works).
(In reply to comment #33)
> "Contact" filtering. First I thought it didn't do anything at all. Then I found
> out it filters according to the "Personal Address Book". But if I "star"
> contacts, they don't even go there, but into "Collected Addresses". And my "Mac
> OS X Address Book" is completely ignored. I'd hope interaction between these
> Thunderbird features can be improved before the integration...

It should be filtering according to both the Personal Address Book and Collected Address book.  The code tries to add all the MDB address books it finds.  You can assist in verifying that the right thing is happening by running Thunderbird with a console open and the "browser.dom.window.dump.enabled" pref set to true.  Then you should see something like the following that tells us how the query is built:

  Search Terms:
    Virtual Folder Terms:
      (none)
    View Terms:
      (none)
    User Terms:
      from,is in ab,moz-abmdbdirectory://abook.mab
      from,is in ab,moz-abmdbdirectory://history.mab
    Scope (Folders):
      Inbox

The OS X address book is not an MDB address book, so it's not surprising that we aren't adding it.  I am unclear on whether it is capable of supporting the required predicate and doing so efficiently; copying Standard8 for input.
(In reply to comment #33)
> 1.
> toolbar button label logic doesn't work well with switching layouts
> (Classic/Vertical). It seems to react to window size, but not thread pane
> width. For me the button labels didn't collapse, shoving the thread pane
> splitter to the right, leaving a "4cm" message pane.

Wow, yeah, that turns out poorly.  Thank you for reporting this!

I don't think the media selector we are using is capable of expressing its constraint against the thread pane rather than the whole window.  I'll change the CSS so that we disable the label text entirely in vertical layout.  If someone wants to come up with something hooked up to resize events that is more thorough *and a mozmill test*, the patch would be gladly accepted.  (The CSS approach we are using is straightforward and simple, but is well short of ideal; it is going to be especially problematic with additional extension contributions.  The upside to the CSS is that the extensions will have a reasonably clean mechanism by which they can affect things.)
(In reply to comment #36)
> (In reply to comment #33)
> > 1.
> > toolbar button label logic doesn't work well with switching layouts
> > (Classic/Vertical). It seems to react to window size, but not thread pane
> > width. For me the button labels didn't collapse, shoving the thread pane
> > splitter to the right, leaving a "4cm" message pane.
> 
> Wow, yeah, that turns out poorly.  Thank you for reporting this!

Bryan fixed this more elegantly based on different feedback and I've pushed his changes in the 0.7 release which should be approved on AMO soon.
(In reply to comment #31)
> Yes, I have a patch that makes anything localizable (anything I found), except
> the red "no results", because I couldn't find it in messageFilterBar.xul
> I've tried the patch for "en-US" and "de".

Thank you for the patch!
An little "issue" (I think related to others that we have in bugzilla) is that when I have a folder sort by date and grouped by sort and check (for example) tag filter, all my groups are collapsed also if the search is raised on a folder with all groups expanded... is a little bit annoying.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100403 Lightning/1.0b2pre Lanikai/3.1b2pre ID:20100403032053

and quick filter prototype 0.7
(In reply to comment #37)
> (In reply to comment #36)
> > (In reply to comment #33)
> > > 1.
> > > toolbar button label logic doesn't work well with switching layouts
> > > (Classic/Vertical). It seems to react to window size, but not thread pane
> > > width. For me the button labels didn't collapse, shoving the thread pane
> > > splitter to the right, leaving a "4cm" message pane.
> > 
> > Wow, yeah, that turns out poorly.  Thank you for reporting this!
> 
> Bryan fixed this more elegantly based on different feedback and I've pushed his
> changes in the 0.7 release which should be approved on AMO soon.

1.
I don't have satisfactory results with version 0.7, it didn't seem to fix this. See the attached screenshot, the labels did not collapse, instead the search box as sole flex-ible element is shoved to minimal width.

2.
The filter button on the tab strip needs a little work, the width changes for me between normal and pressed states.
3.
And, as seen in the screenshot, I just managed to lose it completely (it gets hidden, as it seems, for AccountCentral. It didn't come back when I switched to the mail folder)
With issue that I have described in comment #39, I have also this:
1. select "show in conversation";
2. TB show thread and also quick filter bar, but filterbar don't work.

Should be quick filter bar hide when "show in conversation" or (better) filter bar usable also when conversation is open in a tab.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100404 Lightning/1.0b2pre Lanikai/3.1b2pre ID:20100404033133

and quick filter prototype 0.7
(for bugs find during testing see also comment #41).

Another issue: with quick bar enabled I have a visual issue when (STR):

1. select a message in my Inbox (with "apply default to all messages in the folder..." set off. Use my attached testcase for reproduce the bug;
2. select sent folder in the same account (also this folder has "apply default..." property set off);
3. select Inbox where is stored testcase message: at this point the message is show wrongly. 

As workaround it's need to open the same "wrong" message in a tab: TB reload it and all is displayed right.

When I disable quick search prototype extension all is fine.
(In reply to comment #40)

Thanks for the feedback and checking this out!

> Created an attachment (id=436942) [details]
> Screenshot of Lanikai with proto filter bar 0.7
> 
> (In reply to comment #37)
> > (In reply to comment #36)
> > > (In reply to comment #33)
> > > > 1.
> > > > toolbar button label logic doesn't work well with switching layouts
> > > > (Classic/Vertical). It seems to react to window size, but not thread pane
> > > > width. For me the button labels didn't collapse, shoving the thread pane
> > > > splitter to the right, leaving a "4cm" message pane.
> > > 
> > > Wow, yeah, that turns out poorly.  Thank you for reporting this!
> > 
> > Bryan fixed this more elegantly based on different feedback and I've pushed his
> > changes in the 0.7 release which should be approved on AMO soon.
> 
> 1.
> I don't have satisfactory results with version 0.7, it didn't seem to fix this.
> See the attached screenshot, the labels did not collapse, instead the search
> box as sole flex-ible element is shoved to minimal width.

I don't have an easy fix for this.  The filter bar is looking at your total screen size to determine when to change from icon+text to icon only.  Your screenshot show's a message view of 900px wide, which is much wider than our default wrapping.

We could add a min-width to the input such that it wouldn't fold to such a small / unusable size however that would prevent you from being able to size the windows in this manner (small list, very wide reader). Essentially this setup is the worst possible case.  

I can increase the screen size needed for the vertical view to switch to icon+text mode but that would mean you need a very large screen to ever see the text; something I wanted to avoid.

> 2.
> The filter button on the tab strip needs a little work, the width changes for
> me between normal and pressed states.

I'll take a look at this, I wasn't seeing it before but things could have changed.

> 3.
> And, as seen in the screenshot, I just managed to lose it completely (it gets
> hidden, as it seems, for AccountCentral. It didn't come back when I switched to
> the mail folder)

That seems like a bug but I can't reproduce it on my system.
Bug:

Select a folder sort by date and grouped by sort: raise a filter (for example by "body"): messages count is wrong because if the search find 2 messages in "Old email" node, TB show 3 messages finded (it seem that TB count also "Old email" row as message)
(In reply to comment #43)
> (In reply to comment #40)
> 
> Thanks for the feedback and checking this out!
> 
> > Created an attachment (id=436942) [details] [details]
> > Screenshot of Lanikai with proto filter bar 0.7
> > 
> > (In reply to comment #37)
> > > (In reply to comment #36)
> > > > (In reply to comment #33)
> > > Bryan fixed this more elegantly based on different feedback and I've pushed his
> > > changes in the 0.7 release which should be approved on AMO soon.
> > 
> > 1.
> > I don't have satisfactory results with version 0.7, it didn't seem to fix this.
> > See the attached screenshot, the labels did not collapse, instead the search
> > box as sole flex-ible element is shoved to minimal width.
> 
> I don't have an easy fix for this.  The filter bar is looking at your total
> screen size to determine when to change from icon+text to icon only.  Your
> screenshot show's a message view of 900px wide, which is much wider than our
> default wrapping.
> 
> We could add a min-width to the input such that it wouldn't fold to such a
> small / unusable size however that would prevent you from being able to size
> the windows in this manner (small list, very wide reader). Essentially this
> setup is the worst possible case.

I want to emphasize the importance of this layout on the desktop, with a 22" or >24" screen, not the usual MacBook Pro resolution. In the screenshot I also have Lightning's Today Pane hidden for privacy reasons, normally it takes away from that o-so-wide message pane. The "classic" layout results in insanely long lines of text, and I don't even run TB in fullscreen mode on the 1980px screen.

> I can increase the screen size needed for the vertical view to switch to
> icon+text mode but that would mean you need a very large screen to ever see the
> text; something I wanted to avoid.

I fear although the CSS-solution is so nice and clean, you should go the long way and add a resize/window-width listener in script, giving the flexibility @media lacks here.

> > 3.
> > And, as seen in the screenshot, I just managed to lose it completely (it gets
> > hidden, as it seems, for AccountCentral. It didn't come back when I switched to
> > the mail folder)
> 
> That seems like a bug but I can't reproduce it on my system.

I've only hit this once, right after I setup a new account in Lanikai, I think it had to do with opening a folder for the first time, and the delay caused by that (and bug 499069).
Noticed this bug :

Account 1
 Inbox 30 unread

Account 2
 xxxxxxxx

Account 3
 Inbox 8 unread

Using 0.7 of the extension.

Go to Account 3's Inbox. Select unread emails and press the pin button.
Go to Account 1's inbox -> see screenshot.

Account 1 filtered view will only show the same amount of emails then the filtered view of account 3
One more bug.

I have one account - where I can read
 Inbox (8) meaning that the inbox as 8 unread emails.

When I click on the unread filter - only 7 emails are shown.

View -> Thread with unread after a Sort by thread will show the 8 unread emails. The missing email contains blocked content - could that be the reason why it doesn't show in the filtered view ?
(In reply to comment #45)
> (In reply to comment #43)
> > (In reply to comment #40)
> > > 3.
> > > And, as seen in the screenshot, I just managed to lose it completely (it gets
> > > hidden, as it seems, for AccountCentral. It didn't come back when I switched to
> > > the mail folder)
> > 
> > That seems like a bug but I can't reproduce it on my system.
> 
> I've only hit this once, right after I setup a new account in Lanikai, I think
> it had to do with opening a folder for the first time, and the delay caused by
> that (and bug 499069).

This is definitely a reproducible issue. I just set up Lanikai on a new machine, and when the 3-pane-layout is shown after the intermittent AccountCentral pane, the filter bar and the tab-bar-button don't return.
Blocks: 523443
Another polishing comment:
With Lightning installed the order of tab-bar buttons is unfortunate. Is the order of these tab-bar button extensions controllable, so that the Filter "tab" always appears next to the tab-list button?
Sorry for the bug spam...
Everytime Lanikai launches, the QuickFilter bar is visible/expanded. Is it supposed to persist the state across restarts? Does it stay collapsed for anyone else testing?
(In reply to comment #50)
> Sorry for the bug spam...
> Everytime Lanikai launches, the QuickFilter bar is visible/expanded. Is it
> supposed to persist the state across restarts? Does it stay collapsed for
> anyone else testing?

An excellent question.  The intent is to persist state in the session store.  We don't do this in the extension version because the extension hooks aren't there to do so.  The version we land will have the functionality.
(In reply to comment #43)
> > 2.
> > The filter button on the tab strip needs a little work, the width changes for
> > me between normal and pressed states.
> 
> I'll take a look at this, I wasn't seeing it before but things could have
> changed.

Fixed: http://hg.mozilla.org/users/bugmail_asutherland.org/proto-messagefilterbar/rev/52c2b20e537f

(In reply to comment #49)
> Created an attachment (id=437592) [details]
> Screenshot of tab-bar buttons
> 
> Another polishing comment:
> With Lightning installed the order of tab-bar buttons is unfortunate. Is the
> order of these tab-bar button extensions controllable, so that the Filter "tab"
> always appears next to the tab-list button?

When we land this in trunk the quick filter button will be on the right most of those buttons, but inside of the tab list button.
Bryan, Andrew (or other interested parties), any feedback on my comments 12-15?
They may look long, but it's a list of individual UI issues and bugs where each of these in itself is quite clear and concise (I hope)... :)
FWIW, strongly agree with comment 12 f and g, and comment 13.  (Nothing against the other items.)

with regard to comment 15, note some people report they have hundreds of tags. And so, if it's not fully scalable, be careful it doesn't look ugly in those use cases.
Tags have been raised a number of times.  The built-in tag solution is not intended to be any more scalable than exposed by the rest of the built-in Thunderbird UI.  We are using an arrowscrollbox to avoid having the problem be fatal, but we don't honestly expect it to be usable with high numbers of tags.  Someone with a hundred tags is likely using an extension to deal with that many tags in the first place... ideally that extension or a companion extension would accordingly extend the quick filter bar.

Thomas; your feedback has not gone into the void :).  A lot of the points you raised can only be fixed as the extension is moved into the core which I am about to start doing.  I'll try and call the specific bugs you raised out and point at the appropriate mozmill test.
Speaking of tags and "feedback has not gone into the void", I didn't see any response to my comment 29. I really can't see how to use the tags in this toolbar, because they always assume that tags are things that you want to add to the view, not subtract from the view. That is not how I would normally use tags.
(In reply to comment #56)
> Speaking of tags and "feedback has not gone into the void", I didn't see any
> response to my comment 29. I really can't see how to use the tags in this
> toolbar, because they always assume that tags are things that you want to add
> to the view, not subtract from the view. That is not how I would normally use
> tags.

Bryan had originally proposed (and just now re-confirmed) having right-click be a sorta-secret way to express this without turning everything into a crazy complex widget.  The underlying logic already supports this state, so I'm going to add it and push a new rev of the addon for feedback since it's pretty speculative.
(In reply to comment #57)
> Bryan had originally proposed (and just now re-confirmed) having right-click be
> a sorta-secret way to express this without turning everything into a crazy
> complex widget.  The underlying logic already supports this state, so I'm going
> to add it and push a new rev of the addon for feedback since it's pretty
> speculative.

Version 0.9 is up on AMO and in the repo with this change.  In the process I fixed a tag bug related to switching tabs and a serious general bug with sticky mode active.

We don't have full boolean expressiveness on tags.  Here's the deal:
- If the 'tag' button is pressed, the rule is "the message must have a tag".
- If any of the tags in the expando-bar are checked in normal inclusion mode, messages must have any one of those tags.
- If any of the tags in the expando-bar are checked in exclusion mode (accomplished by right-clicking when checking the box) then the message must not have any of the excluded tags.

Examples of limitations:
1) You want to see all messages (with and without tags) that do not have the 'bad' tag.  The best you can do is all messages (with tags) that do not have the 'bad' tag.

The non-standard right-click magic is specific to the tags implementation and not available on any other attributes.
Someone can reproduce the issue that I have described in comment #42 (use attached email testcase).

I can reproduce it also with latest 0.9 release.
(In reply to comment #59)
It's an anwer :-D

> Someone can reproduce the issue that I have described in comment #42 (use
> attached email testcase).

?
(In reply to comment #60)
> (In reply to comment #59)
> It's an anwer :-D
> 
> > Someone can reproduce the issue that I have described in comment #42 (use
> > attached email testcase).
> 
> ?

grrrrr...
not an aswer :it's a question :-(
Depends on: 525716
I put a comment on the blog. But just a quickie comment here that may need to branch to another bug (neverland).

TB does not have a 'search' or 'find' for messages. It would be nice if we could handle that in here with some sort of option.

[explain]: So far these are filters. For a search or find we need the simple mechanism like 'find in message' but as a 'find in tree(folder)' where one can jump-to, and jump-to-next easily without building a new tree.
(In reply to comment #58)
> (In reply to comment #57)
> 
> Examples of limitations:
> 1) You want to see all messages (with and without tags) that do not have the
> 'bad' tag.  The best you can do is all messages (with tags) that do not have
> the 'bad' tag.
> 
> The non-standard right-click magic is specific to the tags implementation and
> not available on any other attributes.

That is a pretty severe limitation. A common use of tags would be "all messages must have at least one tag", and you really can't use the quick search for that.

Why not extend your right click trick to the main Tag button, so that right clicking on it shows all messages WITHOUT tags, then clicking on individual tags would add them back in.

So a common use case might be that I want my working thread pane to show messages that are either untagged, or tagged Business. So I could simply right click the Tag, then click the Business tag, and I'm hot to trot!

Untagged is a very important state for people who use tagging to classify all messages, as it shows what messages are in need of attention (in this case, classification).
(In reply to comment #35)
> (In reply to comment #33)
> > "Contact" filtering. First I thought it didn't do anything at all. Then I found
> > out it filters according to the "Personal Address Book". But if I "star"
> > contacts, they don't even go there, but into "Collected Addresses". And my "Mac
> > OS X Address Book" is completely ignored. I'd hope interaction between these
> > Thunderbird features can be improved before the integration...
> 
> It should be filtering according to both the Personal Address Book and
> Collected Address book.  The code tries to add all the MDB address books it
> finds.  You can assist in verifying that the right thing is happening by
> running Thunderbird with a console open and the
> "browser.dom.window.dump.enabled" pref set to true.  Then you should see
> something like the following that tells us how the query is built:
> 
>   Search Terms:
>     Virtual Folder Terms:
>       (none)
>     View Terms:
>       (none)
>     User Terms:
>       from,is in ab,moz-abmdbdirectory://abook.mab
>       from,is in ab,moz-abmdbdirectory://history.mab
>     Scope (Folders):
>       Inbox
> 
> The OS X address book is not an MDB address book, so it's not surprising that
> we aren't adding it.  I am unclear on whether it is capable of supporting the
> required predicate and doing so efficiently; copying Standard8 for input.

Okay, by also following the steps above I confirmed it finds contacts from both abook and history.mab.
I hope the other address book(s) can be included in the filter, otherwise it's pretty pointless (at least for me: I have only 5-ish "Collected" contacts, but ~190 contacts in the OS-X address book syncing with the cloud, and my Pre ;)
(In reply to comment #63)
> That is a pretty severe limitation. A common use of tags would be "all messages
> must have at least one tag", and you really can't use the quick search for
> that.

That is what happens when you click the "tags" button.  The example I provided was just intended to convey the limitations of our support for negation, not suggest that we had lost existing functionality (we have not).
 
> Why not extend your right click trick to the main Tag button, so that right
> clicking on it shows all messages WITHOUT tags, then clicking on individual
> tags would add them back in.

It may not be obvious from use, but the tag bar only displays tags that are present in the result set immediately after applying the "must have a tag constraint"; we do a sort of poor-man's faceting by walking the contents of the nsMsgDBView.

While we could do a logically similar sort of thing where, even though we are displaying all the messages without tags, we figure out the tags of the messages that the tag constraint is excluding, it obviously involves a lot more work since we can't just traverse the contents of the nsMsgDBView on-hand.  We would need to spin up a second nsMsgDBView cloned from the first whose search constraints have basically the opposite constraint for the tags applied.

I'm declaring that out of scope for the initial implementation phase and likely extension fodder.

Having said that, the ability to just say "not tagged" (without further tag manipulation) seems useful, but I think we don't want the secret right-click trick to go any further than it has.  The solution that jumps to mind for me would be some visual affordance like a rocker-switch so there are distinct "tagged" and "not tagged" buttons on the toolbar.  Unfortunately I'm not sure the rocker switch is a real thing anymore, let alone a visual metaphor.

> So a common use case might be that I want my working thread pane to show
> messages that are either untagged, or tagged Business. So I could simply right
> click the Tag, then click the Business tag, and I'm hot to trot!

Have you forsaken virtual folders?! :)
 
> Untagged is a very important state for people who use tagging to classify all
> messages, as it shows what messages are in need of attention (in this case,
> classification).

I agree that we are not covering all use-cases.
Status: NEW → ASSIGNED
Whiteboard: [clarkbw working UX will push new extension, asuth has mozmill tests in progress][UXprio] → [asuth converting to core patch]
(In reply to comment #65)
> Having said that, the ability to just say "not tagged" (without further tag
> manipulation) seems useful, but I think we don't want the secret right-click
> trick to go any further than it has.  The solution that jumps to mind for me
> would be some visual affordance like a rocker-switch so there are distinct
> "tagged" and "not tagged" buttons on the toolbar.  Unfortunately I'm not sure
> the rocker switch is a real thing anymore, let alone a visual metaphor.

It occurred to me that this implementation will be inconsistent with the facets filters in the GloDa search page. Granted, that is HTML and this is XUL, but I think the "include/exclude" option should be handled the same way - what would mean that the filter toolbar needs to get that little pop-up menu.
The conversion to a core patch is under way.

I've committed a change to the prototype repository that deletes everything and replaces it with a helpful README pointing at this bug.  Obviously, if you want to use the extension from the hg repo, you will not want to use that revision and are advised to update to the revision before that ("hg up -r ac9741bd681a") and then stop pulling/updating/etc.

The extension will be left as-is on AMO until the functionality is landed in core.  At that point I'll do whatever drastic thing AMO allows me to do to kill the extension and delete the hg repo.

The patch in my patch queue that this is happening on can be found here:
http://hg.mozilla.org/users/bugmail_asutherland.org/comm-central-patches/file/tip/quick-filter-bar

The current state is still in-process and is not usable.  The main notable change thus far is a (hopefully) comprehensive rename to 'quick filter bar' where we once were 'message filter bar'.  

clarkbw, please base any changes to the gloda upsell off the new patch and attach them to this bug.
Whiteboard: [asuth converting to core patch] → [asuth converting to core patch, eta monday]
(In reply to comment #66)
> It occurred to me that this implementation will be inconsistent with the facets
> filters in the GloDa search page. Granted, that is HTML and this is XUL, but I
> think the "include/exclude" option should be handled the same way - what would
> mean that the filter toolbar needs to get that little pop-up menu.

The design bias of the quick filter bar is that you get immediately useful results with each click.  The implementation bias is to pluck the low-effort high-utility fruit on nsMsgDBView.

Although it resembles global faceted search and interface consistency is desirable where appropriate, it is a non-goal to mimic the global faceted search interface or its functionality.

In this case, that translates to us not wanting to have any pop-up menus (and avoiding some of the more complex tag use cases).
(in reply to comment 68)
> Although it resembles global faceted search and interface consistency is
> desirable where appropriate, it is a non-goal to mimic the global faceted
> search interface or its functionality.
> In this case, that translates to us not wanting to have any pop-up menus (and
> avoiding some of the more complex tag use cases).

Well, correct me if I'm wrong, but with the current implementation we're avoiding /all/ tag use cases execpt these:
- msgs with tags (at all)
- msgs with specific tag_a (OR tag_b OR...) (where even tag_x is limited to only those tags that are actually used on the given set of messages.)

IOW, we're covering only a very small and somewhat arbitrary fraction of possible filter scenarios, while excluding even non-complex scenarios like
- msgs with "no tags"
- msgs without tag_a (AND tag_b AND...)
- msgs with tag_a AND tag_b (AND...)
- msgs with "no_tags" OR tag_a (OR...)

I'm aware this is all about "enhancement" since TB2 doesn't have /any/ filters for tags except
- msgs with tag_a (without OR; from View-Button)

I'm worried because looking at the speed at which we're getting complaints and suggestions for tag filtering in this bug, I suppose we'll get a LOT more once "quick filter bar" is out in the wild and people start to realize what they could do with tag filtering but CAN'T do because of limited implementation.

I've been thinking about this, but it's really hard to do a visual implementation of afore-mentioned use-cases based on what we have now. So unfortunately, just statements, no solutions this time...
tag choices should get tooltips, in part so the negation choice is made known.

quick filter (bar) is a great name which differentiates it from existing search methods and old ones (eg quick search). What useful name we can attach to the secondary bar where the tags and "Filter message by" appears? "tag bar", as used in comment 29 and 65, doesn't seem appropriate.
"(quick) filter facets bar", short: ffb ?
I got myself in a situation, by opening multiple 3 panes I think (and closed back down to one pane), where newsgroups won't display thread pane and I see in error console

Error: fixIterator is not defined
Source File: chrome://messagefilterbar/content/messageFilterBar.js
Line: 68
#1) Should the "no matches" tooltip message be improved for multiple filters (filter text set AND buttons pressed)?

STR
1 use quick filter bar to filter for messages that have "search words" (ensure there ARE matches)
2 click on a button from filter bar (like "has attachment")
(ensure that there are NO matches)

Actual result
1 quick filter correctly shows matches for "search words"
2 quick filter fires tooltip message, now claiming "there are NO matches for *search words*...".
This is odd:
- There ARE matches for *search words*
- but not for *search words* AND "has attachment"

Expected result
2 tooltip message should include all filter facets that are currently set (and *altogether* cause "no matches")

Proposed tooltip message (draft; with all filter buttons pressed)
+-----------------------------------------------------------------------------
|There are no matches in the current folder for...
|*search words*
|(/Unread/, /Starred/, /Contacts from Address book/, /Tagged/, /With |attachment/)
|Finish typing what you want to search for and then hit enter to upgrade to a |global search.
+-----------------------------------------------------------------------------

However, one potential problem arising from such added clarity in the tooltip message is that users might expect that we propagate the non-text filters to the global search as well, because of the global search upgrade explanation underneath.
In fact, why not? We already have some of the same facets in global search (starred, attachment). Maybe those others are missing in global search (Unread, Contacts from AB, tagged)?

I'd assume that e.g. when user explicitly sets "Has attachment" in the quick filter, he knows what he's doing and it's unlikely that he's suddenly looking for results that have "no attachment" just because there weren't any matches in the current folder. IOW, propagating non-text facets into the global search "upgrade" might make a lot of sense, IMO.

#2) I'm not getting a "no matches" tooltip message when I press filter buttons only (without typing text), and there are no matches.

#3) We might be confusing the user with the following inconsistent UI:
- On filter bar, pressing buttons will filter for
"criterion1" AND "criterion2", e.g. "starred" AND "tagged".
- On filter facets bar (secondary bar), pressing buttons will filter for
"criterion1" OR "criterion2", e.g. "Important" OR "To do".
IOW, pressing buttons on top or bottom bar doesn't work the same way.
Although I wouldn't expect it to behave differently, certainly not for the top bar (note that we also interpret multiple search words using AND).

4) Furthermore, the tag button states have potential for confusion:
- after click on "has tags" button, all tag buttons are
NOT PRESSED -> meaning: they are /included/ (has "Important", OR "To do" etc.)
- after click on "tag_x" button (e.g. "important"), remaining tag buttons are
NOT PRESSED -> meaning: they are /mostly excluded/ (has "Important", may have others)

I'd think it's the same sort of problem we used to have with original version of global search facets, where you couldn't tell what it means when you click on a facet, and David then added the clarification popup "must involve" / "can't involve", which still isn't clear enough as some users understand "must involve" as an "AND"-criterion (where we treat it as OR).

Again, no easy solutions that I know of, but I thought I'd make this known.
(moving out ETA because I spent my weekend doing taxes instead of working)
Whiteboard: [asuth converting to core patch, eta monday] → [asuth converting to core patch, eta wednesday]
I receive an out-of-band bug report where it appears that the QFB is triggering the age old "if you double stream a message, you can end up with incorrect character set display in the message reader".

I will try and avoid the situation where we are asking the dbView to show something and then almost immediately afterwards ask it to show something else (due to application of query, creation of a query where we had none before, etc.)...

...but we still might want to fix whatever the underlying problem is with the message reader or the db view.
Attached patch v1 core patch with mozmill tests (obsolete) — — Splinter Review 
Right, so this is not final, but it's much better than what the 0.9 version was and is suitable for a first review pass.

The major glaring problem:
- The de-quick-search-ification of the gloda search box is incomplete and has sorta broken things.  If you click the confusing combo-box button, it triggers the gloda search.  Autocomplete is not triggering, and enter would appear not to work.  Also, I haven't disabled any existing quick-search mozmill tests.  (I have disabled the xpcshell tests.)

The main known deficiencies right now:
- gloda upsell needs more styling work
- the gloda upsell tooltip is probably still too aggressive
- mozmill tests need more tab-switching coverage especially in terms of tabs that the quick filter is not supposed to be active on.

I have not yet done a pass of all previously reported bugs in the extension and verified they are fixed and have test coverage.  Some things are just issues with nsMsgDBView implementations and will be punted on; there is at least one nsMsgDBView thing where we have an open bug with a simple fix and I'll do that.

I am not going to spin try builds for this version of the patch because of the gloda search issues.  Hopefully the next patch tomorrow will have that all wrapped up with a bow.
Attachment #436857 - Attachment is obsolete: true
Attachment #439154 - Flags: feedback?(bwinton)
Whiteboard: [asuth converting to core patch, eta wednesday] → [core patch up for initial review by bwinton, patch still needs work though]
Blocks: 542953
Attached patch v2 core patch with mozmill tests (obsolete) — — Splinter Review 
- The gloda search box is all fixed up now.  It even collapses itself when the user turns off gloda (the toolbar customization results are reasonable if suboptimal: it shows up as a 'nothing' space rather than the empty white void if there was nothing there, and it does get its label when you drag it back to the customize dialog.)
- Gloda upsell has been styled per discussion with Bryan.

Still planned/new:
- Checking into whether I broke the results box text alignment...
- Make sure all reported bugs from the extension stage of life have test coverage
- More tab switching test coverage.

I have kicked off try server builds since this should now be generally happy.  Builds will show up here with the 'qfb2' annotation:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=ThunderbirdTry

If someone grabs the builds and specific links have not been posted to the bug yet, please post them.
Attachment #439154 - Attachment is obsolete: true
Attachment #439437 - Flags: feedback?(bwinton)
Attachment #439154 - Flags: feedback?(bwinton)
It occurs to me I should add the alleged reviewer to the cc list...

Blake, you're allegedly the reviewer!  I realize you're in a similar boat, so we might need to shift from you to bienvenu or sid0 as availability and what not allow.  Also, I'm going to hew to the true definition of blocker and say it's fine if this doesn't happen by Tuesday as long as reviewing resources aren't sitting otherwise idle.
Whiteboard: [core patch up for initial review by bwinton, patch still needs work though] → [core patch up for initial review by bwinton, patch still needs more tests]
With the arrival of quickfilterbar, Bug 460737 will be even more exposed. It's inconsistent and confusing for the user that searching for address book's display names works from the global search box, but not from the quickfilterbox. Especially since we always show address book's friendly display names as from header. iow, user knows and sees the friendly name, but can only filter for whatever the sender pleased to chose for the from:-header. So I'll easily be forced to filter for something cryptic like "clarkbw" instead of just typing "Bryan" into my quick filter box.
Depends on: 460737
I've tested the Mac try build and I see little artefacts inside and around the "Filter messages by" buttons, if it is checked.
On my first run I tried to use the unread filter and make it sticky and I changed from my main imap account to a RSS account and the filter wasn't active anymore.
Console had :
Error: There is no active filterer but we want one.
Source File: file:///Applications/Shredder.app/Contents/MacOS/modules/errUtils.js
Line: 100

And I was getting that everytime I was changing folder. Search (the filter one) wasn't doing anything.

After a restart I couldn't reproduce.

Other issue :
Select a folder - filter unread - click on the star filter, nothing happens - if I have or not starred messages in that folder. clicking the star folder on or off produces this in the Error console :
Error: domNode is not defined
Source File: chrome://messenger/content/quickFilterBar.js
Line: 179

The later arrives when ever you set a second filter on (ie it works also if I click on contact).

Filtering by attachment also give the error above.



(In reply to comment #77)
 
> I have kicked off try server builds since this should now be generally happy. 
> Builds will show up here with the 'qfb2' annotation:
> http://tinderbox.mozilla.org/showbuilds.cgi?tree=ThunderbirdTry
> 
> If someone grabs the builds and specific links have not been posted to the bug
> yet, please post them.


Linux :
http://s3.mozillamessaging.com/build/try-server/2010-04-15_19:40-asutherland@asutherland.org-qfb2/asutherland@asutherland.org-qfb2-mail-try-linux.tar.bz2

Mac :
http://s3.mozillamessaging.com/build/try-server/2010-04-15_19:40-asutherland@asutherland.org-qfb2/asutherland@asutherland.org-qfb2-mail-try-mac.dmg

Windows:
http://s3.mozillamessaging.com/build/try-server/2010-04-15_19:40-asutherland@asutherland.org-qfb2/asutherland@asutherland.org-qfb2-mail-try-win32.installer.exe
In fact, Blake raised the flag a little while ago that he was concerned about being too overloaded, and bienvenu graciously offered to handle the review for this bug.  So I'm going to switch the request to him...
Whiteboard: [core patch up for initial review by bwinton, patch still needs more tests] → [core patch up for initial review by bienvenu, patch still needs more tests]
Attachment #439437 - Flags: feedback?(bwinton) → feedback?(bienvenu)
(In reply to comment #79)
> With the arrival of quickfilterbar, Bug 460737 will be even more exposed. It's
> inconsistent and confusing for the user that searching for address book's
> display names works from the global search box, but not from the
> quickfilterbox.

That won't be addressed by this bug, but this bug will make it easier for an extension to address the problem.
No longer depends on: 460737, 525716
Blocks: 525716
(In reply to comment #81)
> Other issue :
> Select a folder - filter unread - click on the star filter, nothing happens -
> if I have or not starred messages in that folder. clicking the star folder on
> or off produces this in the Error console :
> Error: domNode is not defined
> Source File: chrome://messenger/content/quickFilterBar.js
> Line: 179

This seems to happen only in the try-server builds.  I'll look into what's different.  Thanks!
The gloda search box has now two dropmarker. The one in the quick-search-button and on the end of the search box. Both shows the same popup (Filter messages...). For me this is unneeded redundant. The search box better should have a clear button as before.
(In reply to comment #85)
> The gloda search box has now two dropmarker. The one in the quick-search-button
> and on the end of the search box. Both shows the same popup (Filter
> messages...). For me this is unneeded redundant. The search box better should
> have a clear button as before.

Thank you for raising this issue.

This will be addressed in the next patch; this was not fully intentional and upon discussion with clarkbw it was decided that the downsell from gloda to quick filters is not required based on the other ways we promote/introduce it.
Whiteboard: [core patch up for initial review by bienvenu, patch still needs more tests] → [core patch up for initial feedback by bienvenu, some fixes in-progress, more tests required, final patch for first full review eta sunday]
(In reply to comment #44)
> Bug:
> 
> Select a folder sort by date and grouped by sort: raise a filter (for example
> by "body"): messages count is wrong because if the search find 2 messages in
> "Old email" node, TB show 3 messages finded (it seem that TB count also "Old
> email" row as message)

Ugh.  I'm not sure what made me forget that the row count is a visible-rows-in-the-tree-view thing and not a statement about the number of messages.  Situations where threading is enabled will likewise result in nonsensical results.

This can only be addressed in a sane fashion through changes to nsMsgDBView and friends.

The other option is to only provide a boolean indication of results.
(In reply to comment #80)
> I've tested the Mac try build and I see little artefacts inside and around the
> "Filter messages by" buttons, if it is checked.

The theory is that this is a gecko bug.

It would appear that bug 516793 is the best existing bug that covers this problem.

clarkbw, can we just use moz-border-radius (potentially in conjunction with a gradient) instead of pre-generated images?
(In reply to comment #88)
> Ugh.  I'm not sure what made me forget that the row count is a
> visible-rows-in-the-tree-view thing and not a statement about the number of
> messages.  Situations where threading is enabled will likewise result in
> nonsensical results.

Er, the same general problem also intrudes on the tag faceting logic.  That specific use-case may need to be re-engineered to have the 'tag faceting' logic interpose itself in the search listener chain.  That's not an acceptable option when we don't already need to take the hit of having the messages exposed to XPConnect as in the results count, however.
Attachment #437002 - Attachment mime type: message/rfc822 → text/plain
(In reply to comment #45)
> I fear although the CSS-solution is so nice and clean, you should go the long
> way and add a resize/window-width listener in script, giving the flexibility
> @media lacks here.

Agreed.  Overflow/underflow is now handled in script and will be present in the next try build.  We even have a mozmill test.
Whiteboard: [core patch up for initial feedback by bienvenu, some fixes in-progress, more tests required, final patch for first full review eta sunday] → [core patch up for initial feedback by bienvenu, some fixes in-progress, more tests required, final patch for first full review eta tuesday]
(In reply to comment #88)
> Ugh.  I'm not sure what made me forget that the row count is a
> visible-rows-in-the-tree-view thing and not a statement about the number of
> messages.  Situations where threading is enabled will likewise result in
> nonsensical results.
> 
> This can only be addressed in a sane fashion through changes to nsMsgDBView and
> friends.

bienvenu has volunteered to undertake the addition of such an attribute to nsIMsgDBView (on a different bug that will be marked as blocking this bug).
(In reply to comment #89)
> (In reply to comment #80)
> > I've tested the Mac try build and I see little artefacts inside and around the
> > "Filter messages by" buttons, if it is checked.
> 
> The theory is that this is a gecko bug.
> 
> It would appear that bug 516793 is the best existing bug that covers this
> problem.
> 
> clarkbw, can we just use moz-border-radius (potentially in conjunction with a
> gradient) instead of pre-generated images?

clarkbw has provided me with a patch that does this which I have folded into my patch.  This will be present in the next try build.
Attached patch v3 patch, depends on bug 560560. (obsolete) — — Splinter Review 
in-progress patch for bienvenu only.
Attachment #439437 - Attachment is obsolete: true
Attachment #439437 - Flags: feedback?(bienvenu)
Attachment #440361 - Attachment is patch: true
Attachment #440361 - Attachment mime type: application/octet-stream → text/plain
Attached patch v4 patch, for clarkbw to look at (obsolete) — — Splinter Review 

        Attachment #440361 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #95)
> Created an attachment (id=440387) [details]
> v4 patch, for clarkbw to look at

Seems like I need to create an entirely new button if I want to fix the issues with the existing toggle button.  Not a good idea to take this on at this point but I'll see if I can at least override some of the more ugly ways it appears on Linux

    
    

    
  
This patch didn't make it for the string freeze. Adding late-l10n keyword and informing Thunderbird localizers.

Developers should be aware of the process that we have for this, which is detailed at https://developer.mozilla.org/en/Thunderbird_Localization#Breaking_the_string_freeze
Keywords: late-l10n

    
    

    
  


  
After some horrible test problems I brought upon myself after listening to DOM inspector's horrible horrible lies, we now have something suitable for review.

There are a pretty good set of mozmill tests included; not paranoia level of thoroughness, but reasonably comprehensive.  I do not believe they introduce any new mozmill regressions in folder-display (after the removal of the deprecated quick-search test), but since I still experience focus related problems on linux, it's not completely easy to tell.  I'll try and run the suite on my windows box shortly so we can figure that out.

I will initiate a try-server build momentarily.  Based on weirdness from the last try server build, I think it is possible something could still turn out wrong with it, likely suggesting a packaging oversight.

        Attachment #440387 -
        Attachment is obsolete: true

        Attachment #440670 -
        Flags: review?(bienvenu)

    
    

    
  
I saw this mozmill test fail on windows:

TEST-UNEXPECTED-FAIL |  test_buttons_collapse_and_expand
  EXCEPTION: The collapsy bar should be shrunk!
    at: test-display-issues.js line 83
       Error("The collapsy bar should be shrunk!")  0
       assertCollapsed() test-display-issues.js 83
       test_buttons_collapse_and_expand() test-display-issues.js 106
            frame.js 468
            frame.js 520
            frame.js 562
            frame.js 411
            frame.js 568
            server.js 164
            server.js 168

    
    

    
  
Comment on attachment 440670 [details] [diff] [review]
v5 for actual review, has bienvenu nsMsgDBView and search session fixes

This all looks good. r=me, modulo the previous mozmill test failure I mentioned. I still find the filter bar toggler widget odd, but it does have a tooltip...

I think it would be good to get this in soonish so localizers can start working on the strings, and it can get into more testers' hands.

        Attachment #440670 -
        Flags: review?(bienvenu) → review+

    
    

    
  
(In reply to comment #100)
> (From update of attachment 440670 [details] [diff] [review])
> This all looks good. r=me, modulo the previous mozmill test failure I
> mentioned. I still find the filter bar toggler widget odd, but it does have a
> tooltip...

Thanks for the review under time-pressure and with several important code contributions!

I hadn't seen the widget under windows.  I'm unclear if I was running under XP compat mode or Vista mode, but as a linux user I'm jealous of how it looks on windows, so... you could have it worse :)

I'll reproduce/fix/ironclad the test failure you experienced.

> I think it would be good to get this in soonish so localizers can start working
> on the strings, and it can get into more testers' hands.

Agreed.  It turns out the reason my try build last time was broken was because it was using mozilla-central instead of 1.9.2.  So, I can write off my try-build concerns and just make sure the mozmill test is good and then I'll land and watch for obvious burning.

    
    

    
  
(In reply to comment #101)
> I hadn't seen the widget under windows.  I'm unclear if I was running under XP
> compat mode or Vista mode, but as a linux user I'm jealous of how it looks on
> windows, so... you could have it worse :)

It turns out it looks very nice under XP mode and there is entirely no icon whatsoever under Vista/Windows 7.  You may be too easy-going.

I will address this.

    
    

    
  
(In reply to comment #102)
> It turns out it looks very nice under XP mode and there is entirely no icon
> whatsoever under Vista/Windows 7.  You may be too easy-going.

I figured it couldn't be what was intended, but I haven't seen what it should look like :-)

    
    

    
  


  
I completely flubbed the jar.mn update for the windows platform before and missed the aero thing despite the warning message in the file about not doing that.  In my defense, the file does not get syntax highlighted and things that aren't syntax highlighted are invisible to me at this point.

Offsetting that is the fact that I think my mozmill test may have actually been catching the problem (somewhat inadvertently).

        Attachment #440670 -
        Attachment is obsolete: true

        Attachment #440694 -
        Flags: ui-review+

        Attachment #440694 -
        Flags: review+

    
    

    
  
pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/1e333d47863d

I'll mark this fixed once the boxes do their thing and I've notified the l10n newsgroup and what not.
Depends on: 561052
Depends on: 561054
Depends on: 561059

    
    

    
  
Despite some non-trivial hiccups, it stuck, so marking fixed.

Props to clarkbw, andreasn, bienvenu, Standard8, and the whole cast of people who provided useful feedback on this bug and via the other feedback mechanisms!
Status: ASSIGNED → RESOLVED
Closed: 14 years ago

          status-thunderbird3.1:
          --- → beta2-fixed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1b2

    
  
Whiteboard: [core patch up for initial feedback by bienvenu, some fixes in-progress, more tests required, final patch for first full review eta tuesday]

    
    

    
  
Note, the placeholder/emptytext in the quick filter textbox doesn't seem to work.
The emptytext attribute is set, but on the input control the placeholder is not set. 
This is in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100422 Lightning/1.1a1pre Shredder/3.2a1pre

    
  
Depends on: 561320

    
  
Depends on: 561321

    
  
Depends on: 561328
Depends on: 561479

    
  
Depends on: 561534

    
  
Depends on: 561556

    
  
Depends on: 562694

    
  
Depends on: 564280

    
  
Depends on: 564328

    
    

    
  
I just installed and am testing 3.1rc1 and was horrified to discover that the quickfilter box is now on its own 'yet-another-toolbar'...

<sigh>

I understand the argument, but change that reduces usable UI (think netbooks) is change that I have to try to find a way to work around.

I do like the sticky toggle button, but all I want is the old quickfilter with the sticky-toggle beside it.

Also - what is this *invisible* 'Global Search' 'something' taking up space on my menu bar? I can see the words 'Global Search' when I drag it off of the toolbar, but there is nothing butu a blank space on the toolbar when I add it.

So... how can I get my old/original quickfilter (I do not use GLODA, and probably never will, because I use only IMAP accounts with huge mail stores that it is impractical to keep sync'd locally) box back that I can move to the menu toolbar? Please tell me it is doable...

    
    

    
  
Before I go open a new bug/feature request for this new toolbar, I have a
question about the old 'View:' select box for saving/switching custom
views/virtual folders...

How does this fit in with the new Quickfilter toolbar? The 'Read/Unread' toggle
button on the new Quickfilter toolbar is almost redundant with respect to the
pre-defined 'All' and 'Unread' choices on the 'View'' select box, with one
difference... they are not persistent on a per folder basis, like the 'View:'
select box is, and that is the Feature Request I want to open (for the new
buttons on the toolbar to be persistent on a per folder basis)...

So, I guess what I'm asking is, what is the proper way to refer to these new
buttons on the Quickfilter toolbar, and will the 'View:' select box also be
going away/integrated into the Quickfilter toolbar?

Also, for anyone interested, please feel free to vote for my bug 570815 to bring back the Quickfilter searchbox that can be moved to any toolbar, but with the new Sticky pin and the ability to specify any criteria you want via the old select box, as opposed to just the pre-defined combinations.

    
    

    
  
(In reply to comment #108)
> Also - what is this *invisible* 'Global Search' 'something' taking up space on
> my menu bar? I can see the words 'Global Search' when I drag it off of the
> toolbar, but there is nothing butu a blank space on the toolbar when I add it.

It's the global search field. Quick filter function was decoupled from it, and while that resulted in some weird look (two search fields nearby), I personally quite like the result, because it alows both quick filtering and global searching without changing "search engine".

(In reply to comment #109)
> How does this fit in with the new Quickfilter toolbar? The 'Read/Unread' toggle
> button on the new Quickfilter toolbar is almost redundant with respect to the
> pre-defined 'All' and 'Unread' choices on the 'View'' select box, with one
> difference... they are not persistent on a per folder basis, like the 'View:'
> select box is, and that is the Feature Request I want to open (for the new
> buttons on the toolbar to be persistent on a per folder basis)...

I probably don't understand you correctly, but these filters become persistent across folders if you "pin" them using the button on the left.

    
    

    
  
(In reply to comment #110)
> (In reply to comment #108)
>> Also - what is this *invisible* 'Global Search' 'something' taking up
>> space on my menu bar? I can see the words 'Global Search' when I drag
>> it off of the toolbar, but there is nothing butu a blank space on the
>> toolbar when I add it.

> It's the global search field. Quick filter function was decoupled from
> it, and while that resulted in some weird look (two search fields nearby),
> I personally quite like the result, because it alows both quick filtering
> and global searching without changing "search engine".

I don't have a problem with separating the functionality, but that has nothing to do with leaving an INVISIBLE BLOB on the toolbar when GLODA is disable.

> (In reply to comment #109)
>> How does this fit in with the new Quickfilter toolbar? The 'Read/Unread'
>> toggle button on the new Quickfilter toolbar is almost redundant with
>> respect to the pre-defined 'All' and 'Unread' choices on the 'View''
>> select box, with one difference... they are not persistent on a per
>> folder basis, like the 'View:' select box is, and that is the Feature
>> Request I want to open (for the new buttons on the toolbar to be
>> persistent on a per folder basis)...

> I probably don't understand you correctly, but these filters become persistent
> across folders if you "pin" them using the button on the left.

Yes, I wasn't totally clear - I want the little Buttons to be persistent but *not* the text in the Quickfilter searchbox, just like the 'View:' select box is now.

    
    

    
  
Please file new bugs, one per issue, with a clear description and steps to reproduce.

    
    

    
  
(In reply to comment #111)
> I don't have a problem with separating the functionality, but that has nothing
> to do with leaving an INVISIBLE BLOB on the toolbar when GLODA is disable.

You should report it as a separate bug, attach a screenshot to it etc.

> Yes, I wasn't totally clear - I want the little Buttons to be persistent but
> *not* the text in the Quickfilter searchbox, just like the 'View:' select box
> is now.

Search text is part of the filter. I think it's supposed to be persistent along with the rest of the filter, and if you want to loosen the filter when changing folders, you'll just have to delete the contents of the text box. ;)

    
    

    
  
Charles, you have already filed bug 574962, thus there is absolutely no need for you to reiterate this here. As you were told before several times now, please keep topics in their respective bugs.
Depends on: 574962, 575018

    
    

    
  
(In reply to comment #112)
> Please file new bugs, one per issue, with a clear description and steps to
> reproduce.

I plan to, I plainly said I was asking for clarification *before* filing (a) new bug(s)...

    
    

    
  
(In reply to comment #109)
> Before I go open a new bug/feature request for this new toolbar, I have a
> question about the old 'View:' select box for saving/switching custom
> views/virtual folders...
> 
> How does this fit in with the new Quickfilter toolbar?

The "mail views" combo box was left around because the new quick filter toolbar does not provide users with a way to define custom filters.  (Extensions can, of course, contribute new things to the quick filter bar.)

> So, I guess what I'm asking is, what is the proper way to refer to these new
> buttons on the Quickfilter toolbar, and will the 'View:' select box also be
> going away/integrated into the Quickfilter toolbar?

As long as you mention 'quick filter' I think the meaning will be understood.

I am not aware of any plans for further modifications to the "mail views" mechanism, the "quick filter bar", or their interaction at this time.  If someone would like to make changes/enhancements, the way forward at this point the first step would be to implement an extension.

    
    

    
  
(In reply to comment #116)
> I am not aware of any plans for further modifications to the "mail views"
> mechanism, the "quick filter bar", or their interaction at this time.  If
> someone would like to make changes/enhancements, the way forward at this point
> the first step would be to implement an extension.

Thanks Andrew...

Can you comment on whether or not my bug 570815 is doable via an extension?

    
  
Depends on: 573325

    
  
Depends on: 387098

    
  
Depends on: 579576

    
    

    
  
(In reply to Bug 579576 Comment 8)
> (It is my understanding that we intentionally allocated the escape key to
> the quick filter bar as a UX decision. It was, however, my error in letting
> the prototype's hack for accomplishing this regress the stop button.)
> [by hijacking cmd_stop instead of VK_ESCAPE only]

Added documentation for ESC keyboard shortcut to remove quickfilter / hide qfb in major revision 5658 (1), as documented in bug 721666.

- removed "Stop: [ESC]"
- added:

|Clear current Quick Filter; hide Quick Filter Bar||{key Esc} (as often as needed)

(1) https://support.mozillamessaging.com/en-US/kb/keyboard-shortcuts/revision/5658
Depends on: 714041
No longer depends on: 579576

    
  
Depends on: 579576
See Also:  → 1083994

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: