Closed Bug 364519 Opened 18 years ago Closed 16 years ago

[IMAP] On start Saved Search (virtual) folder is hidden

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Thunderbird 3.0b1

People

(Reporter: whimboo, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [non-rdf folder pane will fix this])

version 3 alpha 1 (20061220) Perhaps this could be a regression from the patch on bug 363831. After starting Thunderbird created Saved Search folders on an IMAP account aren't visible until i collapse and expand the account tree. After an restart I can see the same issue.
Seeing this on linux also. I have the saved search stored in a subfolder, collapsing and expanding the parent folder helps too. But i doubt it is fallout from bug 363831, I see this (at least) going back on trunk to 2006-09-13.
OS: Windows XP → All
Hardware: PC → All
Severity: normal → major
Keywords: regression
Tested with some even older builds, I see it even in 2006-07-27 trunk. Didn't have an older build than that to test.
Magnus, you could have a look at the following URL. There are nighly builds available back to 2004. http://archive.mozilla.org/pub/thunderbird/nightly/
Yeah, it's a bit tedious to get a small regression window with builds I have to download though...
(In reply to comment #4) > Yeah, it's a bit tedious to get a small regression window with builds I have to > download though... Ok, I'll have a look on the different trunk builds.
The regression starts between the following builds: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060213 Thunderbird/1.6a1 ID:2006021304 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060214 Thunderbird/1.6a1 ID:2006021410 David, could this be a regression from one of you patches on bug 251296?
I feel like I debugged this a while ago in another bug and put some comments in that bug. I'll see if I can find it. Seems like this could be a blocker though.
Flags: blocking-thunderbird2+
Henrik, are you using the all folders folder view, or a sub-set of the folders?
(In reply to comment #8) > Henrik, are you using the all folders folder view, or a sub-set of the folders? I created a Saved Search folder for the INBOX only with "Match any of the following". It's located directly under Inbox. But I can also move the folder around with the same result.
No longer depends on: 363831
Note that this is trunk only... (but obviously it would be good to fix asap)
clearing blocking flag since this is trunk only.
Flags: blocking-thunderbird2+ → blocking-thunderbird2-
Target Milestone: --- → Thunderbird 3
Scott in comment #7 > I feel like I debugged this a while ago in another bug and put some comments in > that bug. I'll see if I can find it. Seems like this could be a blocker though. Scott, from bug 339865 "This issue was fixed by the work we did in Bug 346747 [states fixes branch and trunk], but I'll leave this bug closed as a non dupe since it should be tested separately."
Requesting blocking thunderbird3 flag as already stated by mscott in comment 7.
Flags: blocking-thunderbird3?
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=ThunderbirdTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-02-13+04%3A00%3A00&maxdate=2006-02-14+10%3A00%3A00&cvsroot=%2Fcvsroot My bet is it's fallout from the thread branch landing back then. This also affects seamonkey.
Assignee: mscott → nobody
Component: General → MailNews: Backend
Product: Thunderbird → Core
QA Contact: general → backend
Summary: [IMAP] Saved Search folder hidden when starting Thunderbird → [IMAP] Saved Search folder hidden when starting Thunderbird/Seamonkey
Target Milestone: Thunderbird 3 → ---
Summary: [IMAP] Saved Search folder hidden when starting Thunderbird/Seamonkey → [IMAP] On start Saved Search (virtual) folder is hidden
Product: Core → MailNews Core
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Looks like this was fixed within the last month. Magnus, are you still able to see this bug? For me its WFM with the latest trunk nightly.
Yes still 100% reproducible on linux/trunk for me.
It looks like to be OS dependent. It works on OS X but I can still see the issue on Windows. Or does it also depend on the underlying IMAP server? At home I have Courier and here it's MS Exchange 2003.
I suppose it can be machine dependent - especially if it's fallout from the thread branch landing all kind of timing factors could play in. Server shouldn't matter, as we don't store the saved search on the server. My take is it's purely an ui timing issue of some kind.
So should we mark it as depend on bug 326273 if that will be the cause?
I've traced this a little, and as far as I can tell it's somehow related to getting the proper notifications to the RSS-based folder tree. The virtual subfolders are successfully added to the IMAP folder objects, but the RSS-based folder tree does not update. Because there are plans to replace the RSS-based folder tree with a non-RDF version, I don't think this bug is worth fixing, at least for the TB version.
fwiw still on as you can see the dupe Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3 ID:20081006095651
Target Milestone: --- → Thunderbird 3.0b1
Depends on: 414038
Whiteboard: [non-rdf folder pane will fix this]
This has been fixed by the check in of bug 414038
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Still a problem for seamonkey of course... don't know what the plan is for a sm non-rdf folder pane.
I caanot see this issue anymore with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081224 Shredder/3.0b2pre ID:20081224025847. Magus, could you please double check if it has been fixed? Thanks.
Yes, it's not a problem with thunderbird anymore.
So marking it as verified fixed. Thanks Magnus.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.