saved search folder over a single folder not showing up in the "recent folders" folder view

VERIFIED FIXED

Status

VERIFIED FIXED
13 years ago
13 years ago

People

(Reporter: moco, Assigned: Bienvenu)

Tracking

({fixed1.8.1})

x86
Windows XP
fixed1.8.1

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

saved search folder not showing up in the "recent folders" folder view

at first I thought this was a bug that "when in recent folders view, when I create a saved search folder, it should show up."

but then, even after switch views, and reading messages in the saved search, and switching back to the "recent folders"  view, the saved search did not show up.

note, this was an imap search of folder, on the from header, which I saved as a child of "Local Folders"
(Assignee)

Comment 1

13 years ago
weird, I read this bugmail in a saved search folder in the recent folders view :-) Not sure what could be going on for you. This might be a more general problem with the MRU view and not to do with saved searches - sometimes the MRU view gets a bit confused about which folders to show. Does the saved search still not show up in the recent folders view?
> Does the saved search still not show up in the recent folders view?

no, but maybe the problem is (once again) between the chair and the keyboard.

what makes a search folder "recent"?  Does it mean the mail in the folder is recent, or the search has been run recently?

I did as second search folder (over my imap inbox, but I parented the search to "Local Folders" and that one shows up.  but the original one I created still does not show up in my "recent folder view".  

The difference between the two is one contains slightly older mail (the newest being from 8/1 instead of minutes ago.)
>what makes a search folder "recent"?  Does it mean the mail in the folder is
>recent, or the search has been run recently?

on a related note, if it is based on the date of the mail in the folder, would toggling the read/unread state affect it?
(Assignee)

Comment 4

13 years ago
Opening the folder in the UI is one of the things that should set the MRU time...but looking at lxr, it looks like setting the new flag on the folder, or copying messages into the folder are the only things that set the mru time. But that doesn't seem right - let me debug...
Assignee: mscott → bienvenu
(Assignee)

Comment 5

13 years ago
ah, yes, opening a view on a folder sets the mru time on the folder - so your saved search should have its mru time set.

To back up, it's all based on a property in the db for the folder, "MRUTime". The 15 folders with the largest MRUTime appear in the recent folders view.

Is your saved search over a single folder, not multiple folders?
> Is your saved search over a single folder, not multiple folders?

the search that does show up in the recent folders view is over two folders ("inbox and bugzilla") and the one that doesn't show up in the recent folders view is over one folder ("to file")
(Assignee)

Comment 7

13 years ago
excellent, that's the bug. Changing summary. I see why that it is - we're setting the mru time on the underlying folder in this case, not the saved search.
Status: NEW → ASSIGNED
Summary: saved search folder not showing up in the "recent folders" folder view → saved search folder over a single folder not showing up in the "recent folders" folder view
(Assignee)

Comment 8

13 years ago
Created attachment 232156 [details] [diff] [review]
proposed fix

set MRU time on single folder virtual folder when search is done (we don't know the viewFolder until after Open is done, and when the search is done seemed as good a time as any...)
Attachment #232156 - Flags: superreview?(mscott)

Comment 9

13 years ago
Comment on attachment 232156 [details] [diff] [review]
proposed fix

nsMsgDBView.cpp might need a new line at the end.
Attachment #232156 - Flags: superreview?(mscott) → superreview+
(Assignee)

Comment 10

13 years ago
fixed on trunk and 2.0 branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
verified using version 2 alpha 1 (20060807)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.