From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (WinNT; U) BuildID: 2000103120 if the "file://" URL contains the question sign, browser displays it, but the display is not valid Reproducible: Always Steps to Reproduce: 1. Open the navigator window 2. Enter the following URL in the URL editor: "file:///C|/?" Actual Results: browser displays several times the icon of drive "C:". The number of icons is equal to the number of files and subfolders in the root of "C:". Also it displays several times icons of drive "C:" as subfolders of drive "C:" (etc recursively) Expected Results: browser displays the error message this situation may occur when trying to open file from Windows Explorer, if the path for that file contains unconvertible Unicode characters.

Sounds like we aren't properly escaping unicode characters

Confirmed with build id 2000110304 on WinNT SP6A spanish version. Probably it could have something in common with bud id: 45966 also could be helpful to take a look at recent discussion on bugtraq about Unicode implementation: http://search.securityfocus.com/search.html

->dougt

mass move, v2. qa to me.

what is milestone "mozilla1.0" anyway? Moving to future.

qa to me, +testcase CONFIREMD: MacOS, Mozlla 0.9. "?" is not "unsafe" in RFC 1739, nor "reserved" by file: URLs in RFC 1739, so they should be acceptable. However, if you create a file in MacOS called "?", when you mouse over the file in a directory display, the URL is displayed with a filename: "%3F". Maybe this reveals a hidden bug w/ the way the directory view works?

No, ? is not unsafe, but we regard it as reserved since ? is used to mark querys in urls. That also happens with file urls, so we escape a ? in a filename to prevent interpreting ? as start of a query. No error here. The problem lies in the interpretation of the question mark depending on the os. First of all the ? gets unescaped again when converting to nsIFile. Then what happens: Can't speak fot the mac, but if there can be a file named ? it should be found. Same for unix/linux. On windows there can not be a file named ? because ? is a wildcard. dir ? shows all files with exactly one character. The place to look is in the nsIFile implementations.

Uh, filesystems don't do queries, right? that's an HTTP convention... Lets say it's not reserved, then it should be allowed (not-escaped), then sent to the OS, unless I missed something else. I thought that "?" was a shell convention in DOS, but that no actual file names can say "?".

Yes, filesystems don't do queries, but the generic uri syntax (rfc 2396) defines the ? as a reserved character. In any case, that should not matter, since we unescape a file url before converting it into a local filepath. What happens then is entirely up to the OS, may it be a wildcard character or not.

Directory Viewer bugs - Reassigning to XPApps / bryner@netscape.com

-> bbaetz

I'll look into this. We don't report errors on non-existant files, though. I think theres a bug on that.

This can't be fixed until bug 102603 is, so ->future.

*** Bug 115771 has been marked as a duplicate of this bug. ***

+ mozilla 1.0 - "?" is probably legal in plenty of filesystems

*** Bug 98868 has been marked as a duplicate of this bug. ***

+nsbeta1 - this is really ugly, and seems to allow a display of infinite recursion in some situations. confirmed: all plats Is this really a depends on 102603? If you are actually dealing with a directory called "?", it works in file | open and other places: file:///Macintosh%20HD/fileURLs/%3F/text.txt Could it be more of a "XUL dir gets very confused when it is handed a '?' bug?"

This is not a problem now that we are in HTML view, instead, the "?" is ignored, as described in bug 102603. Chimera 0.6 and Mozilla 1.3a, so this is both CFM and Mach-O

adt: nsbeta1-

"file:///C|/?" this just pulls up a list of files and folders in the root of my C: drive. It looks like "?" is just treated as a marker for the start of a query string.