Closed Bug 365393 Opened 18 years ago Closed 14 years ago

no way to refresh saved search

Categories

(Thunderbird :: Mail Window Front End, enhancement)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 267997

People

(Reporter: amichai2, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Build Identifier: version 2 beta 1 (20061206) when working on a saved search folder, processing and modifying messages, there's no way to refresh the saved search so that the changes are reflected. Reproducible: Always Steps to Reproduce: 1. create a saved search which shows messages with status 'starred' or 'new'. 2. mark a bunch of messages, some as starred and some as new (or get new mail). 3. work on the saved search folder - unstar some message, and read some of the new ones so that they become marked as read (no longer new). Actual Results: the saved search still shows all of the messages, even though some of them no longer match the search criteria. This is acceptable so that you can still see the messages you've just worked on, but there's no way to manually refresh the folder at any point if you do want to see the changes reflected, other than to move to a different folder and come back to the saved search. Even getting new mail (pressing F5) doesn't refresh the saved search to reflect those changes. Expected Results: it should be possible to manually and/or automatically refresh the saved search folder to re-evaluate the messages against the search criteria, and reflect the current state of the messages.
Don't personally see a strong need for this, but then I don't operate much in saved folders. the manual method is of course to click another folder and come back, or change view. confirming (don't see a dup), but perhaps it's a wontfix.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Assignee: mscott → nobody
I can confirm this tb2 and 3, but: -I consider *correct* to not immediately update read/unread as you mark them till leave folder. This is the same as in newsgroup marking K or other and preserves the view for easy change your mind or accidental mark. -Not having another refresh from inside vfolder is quite the issue. So that you need to leave and come back to see things. And that is also not so intuitive. The problem is that this applies to other areas too in the same way, views do not update till leave, ng etc. So basically the change [if considered] should address consistently general refreshing like this. With a browser-like refresh button (just like stop is there ..) or other simple thing. IMO this is not essential, but may be more intuitive. I'll look for dupes for the general matter or other areas ..
This has been bugging me for a long time. It would be great if virtual folders would automatically refresh when new mail arrives. (For comparison, Outlook does this for search folders) The fact that there is no way to manually refresh virtual folders is a big flaw. I have virtual folders that show my unread mail that meets certain criteria. After I've read some mail, or some new unread mail has arrived, I want to refresh the list. I'd be happy to press Ctrl-R, or F5, or even click a button or (sigh) find Refresh buried in a dropdown menu somewhere. But it's disruptive and slow to pick another folder (which has to redraw) then go back and pick the folder I was just in and didn't want to leave in the first place. It's pretty frustrating to see comments suggesting the current behavior is correct or that this could be a wontfix. Imagine if your browser didn't have a refresh button? What if you had to navigate to a different page and then return to reload your URL?
I don't agree with having any refresh button--ideally, it would be redundant. All operations and folder changes should be reflected in saved searches immediately, with no user intervention required. If the user has an IMAP account set to mark messages as deleted, then this should carry forward to the saved search to do what ovidiu is suggesting.
I use 5 imap accounts, and quite a few 'saved search' folders. It is frustrating to click away from the virtual folder and then come back for it to refresh. My accounts being imap, everytime i click away it takes time for the folder to load, which adds to the frustration. The virtual folders should auto refresh on any activity. Please fix this .
Bryan, please provide UX input on virtual folder/saved search refreshing to eliminate messages that no longer match the search. On trunk, virtual folders/saved searches do update to reflect newly added mail. There is a bug where they do not update when messages that already exist that did not match search criteria change to match the criteria. We plan to resolve that. As such, the refresh issue is strictly about when to update the view to no longer show messages that no longer apply. The best solution I can think of is to provide some UI affordance that indicates that the view now includes some messages that do not match the view criteria and that we can refresh the view. The least horrible way to do this I can think of would be to have the folder pane icon gain a subtle overlay that indicates the view is 'stale' and augment the folder pane so that simply clicking on the folder again causes it to go away* (rather than requiring a selection change). I feel like anything more obvious might end up being confusing and annoying... * This may already work? The view code certainly is written to refresh virtual folders if the same folder is selected again; I'm just not sure that the call ever gets made (unless you change tabs... which is a bug).
Note, in bug 466644, when dealing w/ refreshing the list of 'unread' folders, the latest proposal is to never remove the currently selected folder, even if it doesn't qualify for the search anymore. In general, keeping selected messages but removing non-selected ones might work.
Current (2.0.0.21 -- 20090302) behavior for IMAP and POP. I have IMAP (MS Exchange Server) and POP accounts with saved search folders. When my current, actively selected folder is a saved search folder, the folder does get updates. If I am in an IMAP folder, and a new message arrives or the read/unread state of a message changes, those changes appear automatically in my saved search folder. Same with a POP folder -- if a new message arrives (in this case the POP account is configured to check for new messages periodically) and it matches my criteria, it shows up automatically in my list of messages. If a condition of my saved search is to only include "unread" messages, those messages "no longer apply" once the message is read. I don't need a special indicator to tell me that some of the messages no longer apply (per comment #7 above), it's clear since unread messages are in bold and read messages are not. However, I don't want the message to immediately go away. I may be reading a series of new messages and want to go back to the message I just read a moment ago. Nonetheless, when I get caught up I may want to refresh the folder and at that time the read messages should be swept away. To do this today in Thunderbird, I select another folder, then return to the folder I wanted cleaned up. In Outlook (gasp!) simply pressing F5 does the trick. I don't think any fancy indicators or state changes are needed. I think it all works properly and as expected the way it is now. What is lacking, is a way to refresh the folder. *Something* happens to initialize the folder when you first activate it. That is what cleans things up when you move to another folder then back again. Whatever that *something* is, it would be great if there was a way to call it on demand. Then one could right-click on the folder and choose "Refresh". One could map F5 to "Refresh Active Folder". Choirs would sing and there would be much rejoicing. Bug 466644 is a different beast. Don't remove any messages from the search folder until the user requests it (by selecting Refresh).
I swear I already made similar comments about this elsewhere but I can't find them now. A way to refresh the search/virtual folder via a keyboard shortcut or menu item seems like an decent addition, though I'm not sure what the exact menu item / keys should be right now. In previous virtual folder discussions I've tried to maintain that our behaviour models after user expectations and not an exact virtual folder model. This means when new mail arrives we automatically insert it into the folder/view. When you delete a messages we automatically remove it from the folder/view. However when you flag a message, with a star or unread/read we don't automatically update the view. This behaviour modeling is nice for a number of reasons. It tends to just do what users expect (and with a manual refresh they can gain more control). It also tends to help users know where messages went. i.e. When you delete something you have an idea that you should be able to find it again in the trash. When you have a search for 'starred' messages and mis-click, unstarring the wrong message, the message tends to disappear into the ether. Which message was that, where did it go? By keeping the message around until the view is left and returned or manually refreshed we help people keep an understanding of where their messages are/went to. We could try an indicator that the folder/view is no longer current but I don't think it would translate very well for most users. We might be able to offer a "refresh" button that appears, however I think this will create a task for people. That kind of interaction tends to set people into thinking that they have to refresh after they changed something, just because we showed the button. Similarly with an icon or graying out the folder we'll make some people feel that the folder is no longer "good" and they need to refresh to make it better. That behavior is only necessary if they want it, through something like a manual refresh. I know you can also argue this system of "user intentions" provides intentional speed bumps and we could instead make use of good notifications and an undo system to do things faster with similar usability. That's a possible argument but that faster system of interactions comes with new issues that are pretty difficult to work out. Likely that system won't be ready until we all have flying cars.
see also bug 267997
I think essence (and the annoying moment) is where one has to leave and get back to a folder to refresh. Otherwise, the behavior described above (bryan) is ok 1. I'd go for a small refresh button in the right of the folder |[......folder pane ........]| | | | > Root folder | | |-folder1 | | |-folder2 | | |-ssearch x | <-(updated) | |-ssearch y [@] | <-(not updated)refresh sign (curved arrow?) | | also to keep function around the area of interest idea, like header etc .. not necessarily by gray or icon change, not to confuse it... Maybe with an alt text to say what it does? 2. Or just add a context menu item. the key might follow easier (and learnable) + I think this is UI should be thought in combination with bug 419295
I added a related but different feature request for allowing the new search tabs to refresh or update on changes to the view. Check it out here: 365393 Allow searches to be refreshed/updated from search tab https://bugzilla.mozilla.org/show_bug.cgi?id=365393
522908 & 365393 seem to be about the same thing. I move messages to certain folders, based on the search. What I'd love to see implemented is. Once the search is "stale" a refresh button shows up. This would allow me to refresh when I'm ready to do so, as well as let me know things have changed. I also think an F5 should produce the same results. I'd also add that the "open as list" should look more like a button. I had found it, and then the next time I went to look for it, it took me a while, as it's in an "information" row and doesn't really stand out like a button.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.