When browsing the local filesystem via: file://localhost/path/to/place, trying to open a directory or a file with a '#' in its name will simply list the entries in the same directory as that. i.e.: if a/ contains b/, c/, and #/, a/# will list: b/, c/, and #/. If a file with a '#' in it is accessed, the contents of that directory will simply be shown again. CVS checkout on Wed Nov 3 21:42:45 - 22:03:53 PST 1999 Linux 2.3.25, glibc-2.1.2, gcc-2.95.1

Doesn't sound like layout.

This is a funny urlparsing case. # is a special character in an normal url. It separates the reference part from the filename. You can see this funny behaviour when creating a directory xx with file zzz in it and a directory xx#yy with a file yyy in it. When clicking on xx#yy you get zzz as file, because you are really in directory xx. This is ugly but there is little hope here because I can think of some cases where file-URLs could have a ref-part. So we can't dismiss this and treat # as a normal char.

perhaps encoding the url first would help?

This might be an option if the click on the path would deliver the encoded path back. However, what happens if the filepath is typed into the urlbar? # is a character that should be encoded if it is not the ref-character. If we could savely assume that there would be no / after a # in an URL or at least in a file-URL, we could ignore the # in the path and get it right. I currently don't kwow how this will do with # in a filename but it may be a start.

I have now again something working in URLparsing that does ESCAPING/UNESCAPING. Where can I find that stuff that does the directory tree in the layout when viewing file://... ? Want to try something ...

xpfe/components/directory/nsDirectoryViewer.cpp does the http index parsing. Is this what you're after andreas?

making this bug dependent on the url parsing meta bug.

partial fix for this in ANDREAS_URL_BRANCH

Putting on PDT+ radar for beta1.

andreas, is this sucker gone?

This is only partially fixed, because only nsDirectoryViewer is now able to do this kind of stuff for you. It is still possible to put a # in the urlbar as part of a filename and get this mistaken as a REF. Maybe we need a very smart part of webshell which can detect that this # is infact part of a filename and has to be escaped before given to nsStdURL.

I'm able to view dirs with '#' in them, and load files with '#' in the filename. Marking fixed.

With the Feb 09 build, this problem appears to be fixed. Tested under Linux Red Hat 6.0