517202 - Quick Search: Search term sticks across folders, should be cleared

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

[Thomas D. (:thomas8)]

I love the new bmo's new "Search" component for TB, makes it much easier to roll out da bugz 8-)

Starting out from main mail window's inbox (with smart folders if it matters),

1) pick traditional quick search item like "subject",
2) enter search term with few or no matches ("yourname"), press Enter if you feel like --> filters msg list of current folder (ok)
3) without erasing the search term, click on different folder (e.g. Sent)

Actual Results
- search term sticks (is still in quicksearchbox after changing folder)
That's nice, btw, I've been waiting for that feature for long! Keep it!
- unfortunately, the filter isn't applied to the other folder, you are seeing all messages in spite of the filter term set in Quicksearch field.

Expected Results:
- sticky search term as above
- apply that search term filter to the new folder as soon as I change folders

For bonus points, implement a pref for "sticky search" ON or OFF. :)

Comment 1

[Thomas D. (:thomas8)]

Similar Bug 517200 -  [faceted search] Switching between traditional Quicksearch and Search everywhere sometimes causes blank message list although no filter set

Comment 2

[Thomas D. (:thomas8)]

Attachment: Patch: fix viewfilter to persist with searchwords on folderChange

This patch fixes the reverse case of bug 517200 which I already fixed. So I assume David A's bug 517200, comment #7 applies to this one, too:
> I think it's a real bug, which I'd love to fix.
It's another one-line thing, and tested working on my install for basic use cases.

When user changes folder, we are currently persisting only the user-defined search term in the quick search box, but not the actual view filter. This patch fixes the view filter so that it actually persists in the folder the user changed to.

IMO many users will appreciate the persistance, as it spares them from re-entering the search term for each folder. So we are making manual cross-folder filtering a snap: Just click on different folders to check if what you're after is in there or not. Otherwise, just click on "remove filter" button /once/ and continue browsing your folders without any filter set.

+            if (gFolderDisplay.view && this.value) {
+              gFolderDisplay.view.search.quickSearch(Number(this.searchMode), this.value);
+            }

I added this catch to the folderChanged method of search.xml, which gets called by folderDisplay.js to update quicksearch modes according to inbound/outbound folders. So it's getting called for every change of folder.

I am not sure if this is the perfect way to do it, but it works anyway.
You may wish to check if we would do better by just setting
gFolderDisplay.view.search.userTerms
to the actual value of the quicksearch input box, and then hope that this filter will get applied at some later stage (or does it apply as soon as you set .userTerms?). In my patch, I'm simply applying the filter right away while we're in folderChange and doing folder-related quicksearch stuff anyway.

Comment 3

[Thomas D. (:thomas8)]

@Mark: no ü-s this time ;)

Comment 4

[Thomas D. (:thomas8)]

@Wayne: Please don't change my bugs to "minor", as this will just drive me into writing patches! ;)

Comment 5

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 408662 [details] [diff] [review]
Patch: fix viewfilter to persist with searchwords on folderChange

I think we need a little bit more UI to get this in.  The current behavior, while sometimes annoying, avoids a bad usability problem.

The problem is if a person searches in the Inbox and then switches to another folder they will possibly be tricked into thinking the other folder has little or no results.

If we had a better indicator that the search was still applied in that (newly switched to) folder then this patch wouldn't be a problem.

Here are some solutions I thought we could use to help solve this problem.

We could automatically apply the search and show a notification bar that indicates the search is persisting with actions to clear the search.

Or we could not apply the search and use a notification bar to show that the search is no longer persisting with actions to apply it to the currently selected folder.

Comment 6

[Mark Banner (:standard8)]

Comment on attachment 408662 [details] [diff] [review]
Patch: fix viewfilter to persist with searchwords on folderChange

Cancelling flags based on Bryan's comments.

Comment 7

[Thomas D. (:thomas8)]

Attachment: Mockup Screenshot 1: Filter notification bar

Here's a mockup screenshot picturing one of Bryan's ideas in comment #5 (quote below). I not sure if I share Bryan's usability fears concerning the persisting filter across folders, but combined with Bryan's proposal from bug 462578, comment #76, this seems something really interesting to explore.

While notifying people about the active filter, we're also bringing facets to filtering. I am sure this could be made even more useful. E.g. we could make the "search term" clickable and let people choose if they want *search term* or *search* AND *term* or *search* OR *term*. We could let them click on "containing" to choose things like "beginning with", etc., similar to search operators in "Search messages". Using only very small area of screen real estate, we'll expose all these facets and make them easily accessible, which will make filtering a lot more powerful (see also "Power filter", bug 52298).

(In reply to comment #5)
> (From update of attachment 408662 [details] [diff] [review])
> I think we need a little bit more UI to get this in.
> ...
> We could automatically apply the search and show a notification bar that
> indicates the search is persisting with actions to clear the search.

(In reply to bug 462578, comment #76)
> Then I'd suggest adding a "filter type" bar just above the thread list that
> shows the different options for used in this filtering.
> 
> +------------------------------------------------+
> | [x] To  [x] Cc  [x] Bcc  [x] From  [x] Subject |
> +------------------------------------------------+
> |             / thread list /                    |

Comment 8

[Thomas D. (:thomas8)]

Having these "header facets" really makes a lot more sense if combined with "Power filter" (bug 522985; bug no. typo in the previous comment).

Comment 10

[Gervase Markham [:gerv]]

If we decide not to fix this for 3.0 final, we _must_ clear the search bar on folder change. Having the search term remain but do nothing is really confusing.

Gerv

Comment 11

[Thomas D. (:thomas8)]

(In reply to comment #10)
> If we decide not to fix this for 3.0 final, we _must_ clear the search bar on
> folder change. Having the search term remain but do nothing is really
> confusing.

Gerv is right, and that's exactly the reason for this bug, and bug 526574 (which is more like "let's do what we used to do, remove the filter on folder change"). I would hate to provide that patch (clear search bar on folder change), but I could (only if you promise we'll actually implement sticky search filter some time soon...)

Bryan, isn't the presence of user-set filter terms in qs box a sufficient indication that there is a filter set for the current view? This has ever been the case for TB2, the only thing we'd change is the persistance of that filter on folder change.

Comment 12

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to comment #11)
> Bryan, isn't the presence of user-set filter terms in qs box a sufficient
> indication that there is a filter set for the current view? This has ever been
> the case for TB2, the only thing we'd change is the persistance of that filter
> on folder change.

No, I'm sorry.  Most people don't really think about the search box from that point of view.

e.g.
A person goes into their Work folder and searches for "joe@work" and then goes into their Personal folder and sees no messages; they assume that they are all gone.

When that person started the search for "joe@work" they got inline feedback of the filtering action happening (messages started disappearing from the list).  In the Personal folder there is no such feedback appearing, the folder appears already filtered when entered.  Thus there is no difference (except a persistent search string) between entering an empty folder or one where a search is already applied.  We need to fix that issue to make this happen, make people aware that the filter is still applied.

You can claim that the text being there is enough of an indicator but so many other UIs don't adhere to such rules that we can't expect people to really grasp that.  The find bar in Firefox doesn't find all the words in every new page; you have to activate it.  The Google search entry leaves your last search there until you clear it with no consequences to how you browse other pages. etc.

(In reply to comment #10)
> If we decide not to fix this for 3.0 final, we _must_ clear the search bar on
> folder change. Having the search term remain but do nothing is really
> confusing.

I don't feel that we need to actively remove the string, that's why I never wanted to remove it originally.  I'm not sure what's confusing, perhaps it just goes to show that you never really know when a search filter is applied in Thunderbird.

Leaving it around seemed to improve some use cases, like searching for the same subject in multiple folders.  Instead of typing the entry in over and over again you can hop to each folder, focus the search and press enter.

Comment 14

[Chris Boshuizen]

I find it strange that the message count in the status bar DOES reflect the search term, but the filtering does not occur. This is a really strange choice.

I think that the only real solution is:

> We could automatically apply the search and show a notification bar that
> indicates the search is persisting with actions to clear the search.

There are plenty of times I want to search for some search term and realise it isn't in the current folder, and click through several folders to find it. Having to click back in the quicksearch box and hit enter is a waste of time.

Comment 15

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to comment #14)
> I find it strange that the message count in the status bar DOES reflect the
> search term, but the filtering does not occur. This is a really strange choice.

I wasn't aware this was happening, it sounds like a bug to me.

> > We could automatically apply the search and show a notification bar that
> > indicates the search is persisting with actions to clear the search.
> 
> There are plenty of times I want to search for some search term and realise it
> isn't in the current folder, and click through several folders to find it.
> Having to click back in the quicksearch box and hit enter is a waste of time.

Right, I don't think the current system is ideal but always applying the search without indicating it is applied presents a large usability problem we need to avoid.

A minimal indication of the messages "filtering away" as you enter the folder would be a start, however that animation might slow things down a bit and it doesn't really indicate why things are "filtering away".

Comment 17

[Ludovic Hirlimann [:Usul]]

Amending summary for ease of search

Comment 19

[Andrew Sutherland [:asuth] (he/him)]

I've seen this, it's weird, requesting tracking.

Comment 20

[Charles]

Wait, wait...

Is this going to be configurable or not? Please don't do this *again*!

I *like* the old way, and don't *want* the search to be sticky.

At least give an about:config user pref to change it back to the old behavior, *please*!

Comment 21

[Dan Mosedale (:dmosedale, :dmose)]

My suspicion is that this wouldn't block 3.1, but I think this is really a call for clarkbw to make.  Bryan?

Comment 22

[Andrew Sutherland [:asuth] (he/him)]

I know what the problem is from the messagefilterbar prototype.  We can resolve this when we land the messagefilterbar in.  The actual fix isn't particularly hard but the unit tests will be decent sized and there would be some throwaway if we do that now.

Comment 23

[Chris Boshuizen]

I think an about:config user preference is the right thing to do. Some people expect the search to stick. Some others won't get it why the folder pane does not look as they expected, so the only choice I see is to cater to both users.

I don't know how many hundreds of times a day I do a search and change to another folder and find it is not searching, and then have to click in the search box and press enter.  It is a serious work flow problem. I really want to be able to jsut type once, and then click-click-click through the folders as necessary to find the thing I want.

I should point out, that the addition of archiving is going to make this a much more visible problem.  Messages can be moved out much more easily now than in TB2, and it is quite easy to forget that something isn't in the inbox anymore and actually already in the archive. In this case, sticky search will be really useful.

I cannot emphasize how much this feature needs to be fixed in favour of search sticking.

Comment 24

[Chris Boshuizen]

So what is a potential solution?  I think the right thing to do is flash the search box three times.

Enter a search term, hit enter => the message pane filters, and the search box turns green. 
Change folder => the search box flashes three times, the message pane filters.  If there are matching messages, the search box turns green. If there are no matching messages the search box turns red, after flashing. 


*ps: I meant message pane, not folder pane in my message above.

Comment 25

[Allan Beaufour]

I'm from the camp that does not want it to stick, so please yes, make that possible too :) I normally only search in one folder (or I would use the global search).

Comment 26

[Bob Lord]

There are two trains of thought in this bug, and I think they should be teased apart.  They are:

(1) When you change folders, the *behavior* of the client is to *not* apply the search term to the new folder. However, the UI fails to clear the search string. This is a UI bug. The UI does not properly reflect what the client is doing.

(2) The *behavior* of the client should be to make searches sticky. Or not. Or be configurable. Or not. Or the UI should change. Or not. Or...

Number 1 should be a tiny fix to make the UI reflect the current behavior. That should be the focus of this bug. It *should* block the next patch release. 

Number 2 is an interesting discussion about the nature of how search should work, and given all the great comments, UI mockups, etc. it's going to take a while to get right. It should *not* block the next patch release.

Can we open a new bug to discuss larger UI changes in number 2 so we can get the simple fix for #1?

Comment 27

[Allan Beaufour]

(In reply to comment #26)
> Can we open a new bug to discuss larger UI changes in number 2 so we can get
> the simple fix for #1?

(standing ovations)

Comment 28

[Charles]

(In reply to comment #27)
> (In reply to comment #26)
>> Can we open a new bug to discuss larger UI changes in number 2 so we can get
>> the simple fix for #1?

> (standing ovations)

Done - bug 546904

Comment 29

[Daniel Kabs, reporting bugs since 2002]

(In reply to comment #14)
> 
> There are plenty of times I want to search for some search term and realise it
> isn't in the current folder, and click through several folders to find it.
> Having to click back in the quicksearch box and hit enter is a waste of time.

I think for this task (searching across folders) we are supposed to use gloda instead. 

But you are right.

I also prefer quick search over gloda as gloda is unreliable (e.g. see bug 536874).

Comment 30

[Richard Mlynarik]

Still broken and still irritating in 3.0.2.

So now the navel-gazing has been shunted over to Bug 546904,
can't we please have the ACTIVELY MISLEADING search box cleared
out (simplest possible fix, meaning at least it won't be blindingly
wrong, and requires no UI task-map navel gazing) when switching folders?

selectFolder (or whatever; Mozilla code is in Martian to me) should call
ClearQSIfNecessary() and we're done.  Or something one-liner and similar.

Comment 31

[Andrew Sutherland [:asuth] (he/him)]

This is fixed with the landing of bug 545955 which will be available in Thunderbird 3.1 beta 2.

Comment 32

[Charles]

(In reply to comment #31)
> This is fixed with the landing of bug 545955 which will be available in
> Thunderbird 3.1 beta 2.

Yes, but it does so at the expense of a whole new toolbar, and removes my
ability to have the Quicksearch filter on the Menu bar.

I use a netbook heavily, and a minimal UI is very important. Forcing a new
toolbar for no really good reason, is just plain mean... ;)

Seriously - how can I get my old quicksearch box that I can place on my menu
bar back?

Comment 33

[Charles]

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?