User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:220.127.116.11) Gecko/20091007 Lightning/1.0pre SeaMonkey/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:18.104.22.168) Gecko/20091007 Lightning/1.0pre SeaMonkey/2.0 After Upgrading from SM2.0beta2 to 2.0RC build1 the saved "search folders" from "Tools" => "Search Messages" are being treated as if they were newsgroups. Right from the start Seamonkey complains the Newsserver does not offer the group and asks if it shall be deleted. Same procedure on every automatic fetch all xx minutes. Reproducible: Always Steps to Reproduce: 1. Create a Search under "Tools" => "Search Messages" in SM2.0 < RC1 build1 2. Save as search folder 3. Upgrade to SM2.0 RC build1 and fire it up Actual Results: Search folder is being treated as newsgroup which causes annoying dialogs Expected Results: SM should know what a search folder is and act accordingly as it was created by itself
As stated in the de.comm.software.mozilla.nightly-builds NG this can also be experienced (and that way I can confirm it) after creating a search folder on a news account and then trying to get messages for that folder. IOW, this isn't really an upgrade issue. And it happens with Shredder (TB), too. First you'll get a prompt "Would you like to subscribe to <folder>?". If you confirm that you'll from that on get a prompt stating "The newsgroup doesn't appear to exist on the host <host>. Would you like to unsubscribe from it?" when trying to get messages for that folder. If you confirm that the folder will be "unsubscribed" and you'll be back to where you were at the beginning. Furthermore the context menu shows newsgroup-related entries like Subscribe, Unsubscribe and Mark Newsgroup Read but doesn't offer to delete the folder. OTOH if that were possible the result would be interesting since news servers have no Trash folder... Finally, under certain conditions yet to be determined the icon changes from the folder with magnifying glass to a newsgroup icon. I wonder whether this should be "fixed" in such a way that creating search folders on news servers would be prohibited. After all there's always the possibility to create search folders on Local Folders. The only question in that scenario would be how to treat existing folders (upgrade/migration).
Status: UNCONFIRMED → NEW
Ever confirmed: true
That's true, the behaviour Jens Hatlak describes is the one without upgrading. (question to subscribe, icon-changes,...) Forbidding to create such folders in newsgroups should (hopefully) not be necessary as this used to work fine until SM2.0b2 (except the fact that the context-menu offered newsgroup options, which didn't make much sense) and adding search-folders to a certain news-server improves the overview when a folder is related to a specific account/news-server
Component: MailNews: General → Search
Product: SeaMonkey → MailNews Core
QA Contact: mail → search
In my opinion SM can't ship with that. When leaving SM alone for some time where auto-fetching has been performed in the meantime, one is confronted with dozens of dialog boxes one after another to deny the deletion of those folders. Today I got the impression that this even seems to happen when the system has been hibernated (aka. suspend to disk) where this is extreeemely annoying the next day!
Not blocking on this, too few people affected to be blocking the release for everyone out there.
Flags: blocking-seamonkey2.0? → blocking-seamonkey2.0-
(In reply to comment #1) > First you'll get a prompt "Would you like to subscribe to <folder>?". If you > confirm that you'll from that on get a prompt stating "The newsgroup doesn't > appear to exist on the host <host>. I can confirm that, although the latter took several minutes to appear. (In reply to comment #2) > this used to work fine until SM2.0b2 That's roughly only 4-6 weeks of mad check-in fests to search. :-/
Summary: Search folders are mistakenly considered being newsgroups → virtual / saved search folders are mistakenly considered being newsgroups
Hopefully it should be easy to exclude Virtual folders when fetching all newsgroups.
Assignee: nobody → acelists
Created attachment 715770 [details] [diff] [review] patch
Attachment #715770 - Flags: review?(Pidgeot18)
Comment on attachment 715770 [details] [diff] [review] patch Review of attachment 715770 [details] [diff] [review]: ----------------------------------------------------------------- I could be persuaded to take a similar approach to these patches, but I want to see the logic tweaked: iterating over the server should iterate over all the newsgroups of the server instead of all non-virtual folders. You might add a method to nsINntpIncomingServer that returns an nsISimpleEnumerator over all newsgroups instead of child folders.
Attachment #715770 - Flags: review?(Pidgeot18) → review-
Created attachment 734300 [details] [diff] [review] patch v2 Ok, but this does not help much. Even virtual folders have the Newsgroup flag set. The virtual folders even got into newsrc. And if manually removed from there, TB asks if the "newsgroup" (folder) should be subscribed.
Comment on attachment 734300 [details] [diff] [review] patch v2 Review of attachment 734300 [details] [diff] [review]: ----------------------------------------------------------------- The style code of mailnews/news C++ code is brace-on-its-own-line. So, as mentioned, this doesn't actually fix the bug. The steps I want to see forward here are the following: 1. Override nsMsgNewsFolder::GetFlags to clear the newsgroup flag if it's a virtual folder. Add a comment here mentioning that instances of this folder type really shouldn't be virtual folders and note that it's a temporary solution. Include a bug number where we actually discuss this in detail, and preferably file a bug about actually fixing the entire virtual folder setup. (Of course there's nothing so permanent as a temporary solution...) 2. Install an attribute on nsINntpIncomingServer called allNewsgroups or something similar that does the iterate-over-all-folders-with-the-newsgroup flag, and use that instead of these places. That should future-proof the code against a lot of possible future design changes and reduce code duplication.
Attachment #734300 - Flags: review?(Pidgeot18) → review-
You need to log in before you can comment on or make changes to this bug.