With the current build which supports IMAP shared folder, I can open folder access rules window for ASCII imap folders, but i'm unable to open the window for non-ASCII folders. Steps to reproduce: 1. Have a non-ASCII folder in IMAP account. 2. Select the non-ascii folder and open the folder property window for it. 3. Click on Sharing tab 4. click on Privileges button, it doesn't open the access rules window, browser window keeps on trying forever.
On one of my testing accounts firstname.lastname@example.org I have a non-ascii folder tëst, when I open access rules window for this folder, the browser window goes to http://email@example.com:33333/bin/user/admin/bin/mailaclbody.cgi?folder=user/ji3/t%26AOs-st
nominating for nsbeta1.
it looks like we're using the imap mod-utf7 folder name, which is what I would tink the server wants. I'd check with the admin server people to see how they want the admin urls encoded.
UTF-8 has to be used according to RFC 2192. http://www.ietf.org/rfc/rfc2192.txt > 9. Multinational Considerations > > IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding > non-US-ASCII characters in IMAP mailbox names. Because this > convention is private to IMAP, it is necessary to convert IMAP's > encoding to one that can be more easily interpreted by a URL > display program. For this reason, IMAP's modified UTF-7 encoding > for mailboxes MUST be converted to UTF-8 [UTF8]. Since 8-bit > characters are not permitted in URLs, the UTF-8 characters are > encoded as required by the URL specification [BASIC-URL]. Sample > code is included in Appendix A to demonstrate this conversion. cc to taka reassign to putterman
Assignee: nhotta → putterman
Assignee: putterman → bienvenu
Discussed in Mail News bug mtg with Engineering QA and PjM. Decided to ADT2 and plus this bug.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla1.0
actually, we're just running the url we get back from the server, so this really should be up to the server.
Can you try this with 4.x? I strongly suspect this is a problem on the server, since, as I said before, we just turn around and run the url the server gives us.
4.x doesn't have this problem. It can open the privileges window for non-ASCII folders.
do you mean non 7-bit ascii? I have a folder with lots of 8 bit character names that I can launch the admin ui through privileges in Mozilla (the same folder doesn't work at all in 4.x - I can't even select it). If you could tell me how to create a folder with a name that doesn't work, or point me at a test account, I could start debugging this. (your url doesn't work at all for me in 4.x or Mozilla) However, since all the mail code is doing is running an http url given to us by the server, there's not going to be anything I can do in my code. There might be a browser problem, or a necko problem, but it's really just pass-through code as far as the imap code is concerned.
Sorry, I should have explained in more details. Please use the testing account below: sever name: seamonkey.mcom.com usrid: ji3 passwd: ji3 I have tëst folder on this account, or you can create a non 7-bit folder by copy/paste a French or German string from website. On 4.x, the URL is not working, but I can go to the end user page at http://seamonkey.mcom.com:33333/bin/user/admin/bin/enduser and set folder permissions from there. On Mozilla, it doesn't show this enduser url, the browser is just trying to open the url, so the user can't get around the url problem. Since the url itself doesn't seem to be working even on 4.x, it does look like a server problem.
This problem was seen with 4.x Messenger server. With 6.0 server, the UI at server side is changed, and I don't see this problem with the new version of the server.
Summary: Unable to open folder access rules window for non-ASCII IMAP folders → Unable to open folder access rules window for non-ASCII IMAP folders on 4.x servers
this is a browser bug - we need to find someone on the browser side to handle this.
Rick, can you give me some hints here? We're running a url given to us by the mail server - we get challenged for a user name+password, and after I enter that, we start running the url in a new browser window, but it just spins and spins. My suspicion is that the server is redirecting us, and this redirection fails because we ran the url in our mail window doc shell with this line of code: rv = docShell->LoadURI(uri, nsnull, nsIWebNavigation::LOAD_FLAGS_IS_LINK, PR_FALSE); I tried passing in PR_TRUE for the firstParty parameter and that didn't work either (not that I know what the firstParty parameter means). I also discovered that clicking on this url in a mail message works, so there must be something about the docshell call that isn't right (or some magic that happens when you click on a link...) If we stop the url in the browser window and then just hit return in the url bar to rerun the url, it works fine.
This can't be an ATD2 bug for the mail client since it's a 4.x Mail server bug, right? Yes, the redirect should succeed and display the server error page, but even if it does, the mail server is just going to display an error page saying it can't find the folder since it's not dealing with the same url it gave the client (this works in 6.x server)
making nsbeta1- since even if we made it show the error page the user still couldn't do anything when using a 4.x server.
Keywords: nsbeta1+ → nsbeta1-
iqa: do you agree with the decision?
*** Bug 139854 has been marked as a duplicate of this bug. ***
I think we can provide the end user URL on the error msg page as Communicator 4.x does, so the user can go to that page to set privileges for non-ascii IMAP folders, a workaround for this problem.
Well, this is not working for 6.0 server either, as far as I18N's concerned. 1.0RC1 sends folder name in modified UTF-7 encoding without specifying charset using 'charset=' argument in URL. In WMAP, it's expected to use 'charset=" to specify charset for embedded string in URL when it's beyond US-ASCII. It's okay to use modified UTF-7 for folder name as far as it's URL safe and given with appropriate 'charset=' argument.
Never mind. I've got a fix on server side for 6.x releases.
hey david, i can't think of any good reasons why the call to LoadURI(...) should fail for your docshell... my only thought is that 'maybe' it has to do with EventQueues :-( I could imagine things wouldn't work 'quite right' if a new browser window was created while mozilla was sitting inside of a modal event loop for the password auth dialog... i think that the 'current event queue' gets cached in a couple of places... so, this cached queue would be wrong... and 'possibly' events wouldn't get dispatched correctly... does this sound plausible?? or am i just babbling again... this is the only senario i can come up with... -- rick
Rick, that's plausible. There are enough goofy things going on that event queues might be involved. Maybe I'll try running the url *after* the property dialog is dismissed and see if that works, if so, it would point at the modal dialog and not the way I'm running the url.
can't reproduce on 2002-06-14-08-1.0.0 Windows XP pro. JA & Mac OS 9.1 JA
Gary, see this?
Product: Core → MailNews Core
:Bienvenu I think everyone here is gone :Bienvenu in comment #23 > Rick, that's plausible. There are enough goofy things going on that event > queues > might be involved. Maybe I'll try running the url *after* the property dialog > is > dismissed and see if that works, if so, it would point at the modal dialog and > not the way I'm running the url. Kasumi in comment #24 > can't reproduce on 2002-06-14-08-1.0.0 > Windows XP pro. JA & Mac OS 9.1 JA
QA Contact: ji → i18n
we don't support the privileges button anymore - marking invalid
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
Privileges button still exists.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Really? What server are you using so that you see the privileges button? In any case, I won't be working on this anytime soon.
Assignee: bienvenu → nobody
I believe it's an iPlanet Messaging Server. Not that i can actually do anything after clicking it, the link isn't accessible.
my inclination would be to just remove the button - if someone has a use for it, they can write an extension.
Well it's a fairly good way to set privileges (if the server side would be properly configured). On the other hand, i'm not sure this bug is actually valid. The quote in comment 4 talks about and what an "URL display program" should use. The question here is wheter the folder name sent in the url should be urlencoded or if modified utf-7 is ok.
You need to log in before you can comment on or make changes to this bug.