Unable to open folder access rules window for non-ASCII IMAP folders on 4.x servers

REOPENED
Unassigned

Status

REOPENED
17 years ago
10 years ago

People

(Reporter: ji, Unassigned)

Tracking

({intl})

Trunk
mozilla1.0
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
On one of my testing accounts ji3@seamonkey.mcom.com
I have a non-ascii folder tëst, when I open access rules window for this folder,
the browser window goes to 
http://ji3@seamonkey.mcom.com:33333/bin/user/admin/bin/mailaclbody.cgi?folder=user/ji3/t%26AOs-st
Keywords: intl
(Reporter)

Comment 2

17 years ago
nominating for nsbeta1.
Keywords: nsbeta1

Comment 3

17 years ago
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.

Comment 4

17 years ago
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

Comment 5

17 years ago
taking
Assignee: putterman → bienvenu

Comment 6

17 years ago
Discussed in Mail News bug mtg with Engineering QA and PjM.  Decided to ADT2 and
plus this bug.  
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [ADT2]
Target Milestone: --- → mozilla1.0

Comment 7

17 years ago
actually, we're just running the url we get back from the server, so this really
should be up to the server.

Comment 8

17 years ago
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.
(Reporter)

Comment 9

17 years ago
4.x doesn't have this problem. It can open the privileges window for non-ASCII
folders.

Comment 10

17 years ago
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.
(Reporter)

Comment 11

17 years ago
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.
(Reporter)

Comment 12

17 years ago
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

Comment 13

17 years ago
this is a browser bug - we need to find someone on the browser side to handle this.

Comment 14

17 years ago
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.

Comment 15

17 years ago
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)

Comment 16

17 years ago
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-
Whiteboard: [ADT2]

Comment 17

17 years ago
iqa: do you agree with the decision?

Comment 18

17 years ago
*** Bug 139854 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 19

17 years ago
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.

Comment 20

17 years ago
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.

Comment 21

17 years ago
Never mind.  I've got a fix on server side for 6.x releases.

Comment 22

17 years ago
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

Comment 23

17 years ago
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.

Comment 24

17 years ago
can't reproduce on 2002-06-14-08-1.0.0
Windows XP pro. JA & Mac OS 9.1 JA
Product: MailNews → Core
Gary, see this?
(Assignee)

Updated

11 years ago
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

Comment 27

10 years ago
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 → ---

Comment 29

10 years ago
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.

Comment 31

10 years ago
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.