Closed Bug 226151 Opened 22 years ago Closed 22 years ago

new folder doesn't show up in the folder list pane

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: rjl, Assigned: Bienvenu)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110 Creating new folder when creating a new filter does not show the folder name in the folder list pane until Mozilla/Mail is restarted. Reproducible: Always Steps to Reproduce: 1. Right click on a message and select "Create Filter From Message". 2. Click on "New Folder". 3. Select any folder as the parent and enter any folder name. 4. Press return or select the "OK" button and the folder is created but doesn't show up in the folder list until Mozilla/Mail is restarted. Actual Results: The folder name was not visible. Expected Results: The folder name should have immediately appeared in the folder list pane.
*** This bug has been marked as a duplicate of 225235 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Component: Filters → Mail Window Front End
Resolution: --- → DUPLICATE
Unduping. After mucking around with this new folder business for awhile, I noticed that there are still issues with existing subfolders. That is, if the new folder is directly under Inbox, then this works. However, if the new folder is a subfolder of a folder under Inbox, then this problem occurs.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Confirming. To reproduce this bug one does not need to have to go through the create filter dialog. Just right click on an existing Inbox folder and select 'New Subfolder'. Type in a file name and hit enter. It appears that nothing has happened, but if you hit enter again, you get the "A folder with that name already exists message" If you close Mozilla and re-open, you will see that the (sub)folder was indeed created. This looks to be the same issue as bug 2255235 (I get the same "line 0: uncaught exception: [Exception... "Component returned failure code: 0x80550013 [nsIRDFCompositeDataSource.DoCommand]" JS error mentioned in that bug), with the difference being that this is for a subfolder. Fixing this bug would fix bug 226150 as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Charles, have you tried a build from 11/11? I believe this is all fixed.
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → WORKSFORME
David, Apologies for not stating as such, but the problems I see with subfolders are occurring on a current trunk build. The problem with folders was indeed fixed, it's just that it looks like a problem still exists with subfolders
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Flags: blocking1.6?
This seems to work for me using 2003121014 on Linux. Could anyone verify this?
related to bug 225372 or bug 225371? Are all of these can't write bugs fixed in the latest nightly builds? Bienvenu, is there a fixed bug these should be duped against?
I thought this was a dup of bug 225235 - bug 224849 is also related.
When I first came across this bug and did a little bit of testing I thought it to be a dupe of bug 225235 (,which through testing, I observed to be fixed). However, after playing around for a little bit I saw a problem. I could create a subfolder of the Inbox 'Foo' just fine. However, if I tried to make a subfolder of 'Foo' (calling it 'Bar'), then the folder would not be created (I would get the same error as in bug 225235). (Comment 3 details my observations at the time .) I tried again tonight. I created a subfolder of Inbox 'Spam' just fine. I closed out and created a subfolder of 'Spam' (called 'Eggs') just fine. However, when I tried to create a subfolder of 'Foo' (called 'Gaz') I encountered the problem previously reported. This is probably related to bug 225371 in that I was able to delete 'Spam' and its subfolder. I am not, however, able to delete 'Foo' or its subfolders. (All of this testing ocurred on CVS builds that were/are current.)
I'll try it out.
Assignee: sspitzer → bienvenu
Status: REOPENED → NEW
I'm not able to reproduce this. I tried before the first time you said you were still having the problem and couldn't reproduce it then, either. I'm not sure what's going on here...
not going to hold 1.6 for a problem that we can't reproduce.
Flags: blocking1.6? → blocking1.6-
Does anyone still see this? Or may I mark this WFM?
Bug Day Yeah, this WorksForMe now as well... since I confirmed it, I'll mark it as such...
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.