When I open a imap4 account in the mailcomponent, then the (almost complete) folderstructure is displayed. As soon as I click on the "subscribe" poup menuitem (after a right-click on the folder), mozilla crashes. A talkback for this is TB22163543W The IMAP Server is Groupwise 5.5.4 with the Enhancementpack SP2 Andre
Sorry for forgetting this: Build: 2000113004 Running on W2000 The same crash occurs when I hit the subscribe-menu item under "File" in the mail menubar.
WFM, I did not crash while repeating the steps listed. OS: Win2k SP1 Moz Build: 2000120308 Talkback User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001203
Build: 2000121404 This crash seems to only occure, when we have a imap-folder who has "umlaute" in it like צה�. As soon as I rename those folders to names without umlautes, then I can subscribe just fine. Andre.
Summary: Crash when I click the Subscribe-popup menu item on a IMAP folder → Crash with "umlaute" in Subscribe box
Can anyone else confirm this and mark it NEW?
Ccing momoi. momoi, can you check? Is this your testing area? It seems that I cannot reproduce this problem since my testing is not covering this area.......
With the 12/19/2000 Wi32 build, I could not reproduce the crash problem. But I am using Netscape IMAP server. Since there is an interaction with the server when you use teh subscribe menu, it is possible that the problem may be specific to Groupwise 5.5.4 server. André, do you have access to non-Groupwise IMAP server and can reproduce the same problem?
I tested it against a NTMail imap server (From gordano) and there it works. So it's a problem who occurs when the IMAP Server is Groupwise. But Mozilla should handle this a bit more sophisticated, since with Outlook & Netscape 4.x this worked fine, against the groupwise server.
>This crash seems to only occure, when we have a imap-folder who has "umlaute" >in it like צה�. >As soon as I rename those folders to names without umlautes, then I can >subscribe just fine. Based on reporter's test scenario, changing QA contact to momoi.
QA Contact: huang → momoi
André, do you have access to an error log on the Groupwise server? Is there a crash report (Talkback) generated from Mozilla? We need a log of the client-server interaction to be able to see where we are dying. I am going to confirm this bug so people concerned about this problem can go forward to investigate. We need André's help in going forward as we don't have Groupwise IMAP server around here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
One of first TB I had is TB22163543W , and TB23369495Z is a new one with Build 2000122020 Yes, I have full access on all options the groupwise server has (I'm the administrator of it) Here the maximum IMAP-protocoll I can provide you from the serverside: 12-21-00 11:30:28 9 Accepted IMAP4 connection with: 184.108.40.206 12-21-00 11:30:40 9 IMAP4 command: Server - 1 OK LOGIN completed 12-21-00 11:30:40 9 IMAP4 command: Client - 2 LSUB "" "*" 12-21-00 11:30:47 9 IMAP4 command: Server - 2 OK LSUB completed 12-21-00 11:30:47 9 IMAP4 command: Client - 3 LIST "" "INBOX" 12-21-00 11:30:47 9 IMAP4 command: Server - 3 OK LIST completed 12-21-00 11:30:47 9 IMAP4 command: Client - 4 LSUB "" "*" 12-21-00 11:30:47 9 IMAP4 command: Server - 4 OK LSUB completed 12-21-00 11:30:47 9 IMAP4 command: Client - 5 LIST "" "%" 12-21-00 11:30:47 9 IMAP4 command: Server - 5 OK LIST completed 12-21-00 11:30:49 9 IMAP4 command: Client - 6 LIST "" "%/%" 12-21-00 11:30:49 9 IMAP4 command: Server - 6 OK LIST completed 12-21-00 11:30:51 9 IMAP4 session ended: 220.127.116.11 I can provide a account on the groupwise imap server who can be accessed from the internet to test this behaviour. But of course I will not put the details here... ;-)
QA contact to marina.
QA Contact: momoi → marina
André, is it still happening? If yes, could you provide us with testing account because we are not able to reproduce this problem otherwise.
With build 2001031204 it no longer crashes, but the behaviour is still not correct. Imapserver 18.104.22.168 Username: Mozilla Password: bugzilla In the Folder Cabinet there are two Subfolders. One called Unterordner and the second one is Aufträge In Mozilla I actually get a Unterordner and a Cabinet. The "Cabinet" is wrong, here a Aufträge folder should show up. In both folder I have put one message. In Netscape 4.7x I at least get a "Auftrge" folder (just stripped away umlauts) André.
removing crash keyword since this doesn't cause a crash anymore. load balancing to naving...assuming he's willing =).
Assignee: mscott → naving
Andre, may i experiment with your IMAP account on 22.214.171.124? eg: create/delete folders ( i am seeing now as you described no intl chars in folder's name)? Thanks.
Are those folders (Unterordner and Aufträge) created from Mozilla?
this bug is reproducable only when IMAP server is Groupwise (using mozilla build)
i tried to create a non-ascii folder on this IMAP server but the non-ascii folder is not showing up on the imap tree( close/reopen/restart to reconnect to the server doesn't help) though it does show up under the Profiles as #.msf as well as the Auftr#ge.msf
Summary: Crash with "umlaute" in Subscribe box → Groupwise IMAP: Crash with "umlaute" in Subscribe box
With Groupwise 6.0 and Mozilla build 2001102808 it works fine. So either it's solved with the new builds, or groupwise 6.0 handles it better. Since we no longer have a 5.5 server to test against it.... should I close the bug ?
Marking wfm based on last comment.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
it would be still interesting to see whether new builds work with Groupwise server 5.5...so that we know what fixed the problem : the upgrade or the build ( i am inclined to think it's the server upgrade). If you feel comfortable i'll resolve this bug as WFM and if the problem resurface you can reopen this bug.
I don't think I will come in a situation I will have to repoen the bug. (Since all our clients upgraeded from 5.5 to 6.x) So this is just fine. André.
Thanks. Verifying as wfm
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.