If we have a file or directory with a real % character in their filenames, Mozilla doesn't attempt to escape the % character. As a result, the file cannot be opened. For example, make a file called "%7Echimera", under Netscape 4.x, when you click on the filename (typing it in doesn't count), Netscape automatically converts this to %257Echimera. Mozilla doesn't. BTW %7E is a tilde and %25 is the percentage sign.

There are actually multiple failures here: when Mozilla doesn't mangle the URL, it doesn't load; when Mozilla does mangle the URL, it does load. Steps to Reproduce: 0. Save or rename a file in a directory reachable by a localhost webserver called &7Echimera.html 1. Type a file:// URL into the URL bar for that file. 2. Lop off the filename from that URL, and then click on &7Echimera.html 3. In the "Open File" dialog, navigate to the file and click [Ok]. 4. Type a http:// URL into the URL bar for that file. 5. In the "Open Web Location" dialog, type in the same URL. Actual Results: 1. %257Echimera.html in URL bar; page displays. 2. %7Echimera in URL bar; page does not display. 3. %257Echimera.html in URL bar; page displays. 4. %257Echimera.html in URL bar; page displays. 5. %7Echimera.html in URL bar; 404 error; "~chimera.html was not found on this server" Expected Results: For all: %7E in URL bar; page diaplays. Result 5 could perhaps be expected, if apache is translating the URL itself. Tested with: 2000-02-03-10-M14 nightly binary on Windows NT 4.0sp3. I have a sneaking suspicion this may turn out to be a DUP...

Andreas do your latest changes fix this?

No they don't, at least in this case. Escaping/Unescaping is now in, but in this case it fails, because it thinks, %7Echimera.html is already escaped. This seems to be a no win scenario, what ever we do, someone will break, because we escape to much or not at all.

someone wanna volunteer and dig up behaviour from a 4.* browser? Just so we can close in on doing the Right Thing.

OK, running through the steps with NN 4.7 on WinNT: 1. Does not work; alert box comes up: no such file. 2. %257Echimera.html in URL bar; page displays. 3. %7Echimera.html in Open Page dialog; alert box comes up: no such file. 4. %7Echimera.html in URL bar; 404 error; "~chimera.html was not found on this server" 5. %7Echimera.html in URL bar; 404 error; "~chimera.html was not found on this server" 6. %257Echimera.html in URL bar; page displays. Step 6 is the same as step 2 for http: instead of file: All told, Mozilla is doing more useful now than NN 4.7, in the way of displaying the page, but is getting the page displayed where NN 4.7 doesn't only when it escapes the URL where 4.7 does not. So which is better, seeing the file but changing the URL, or keeping the URL accurate but not seeing the file?

Hmmm ... one thing can be fixed. I have a change in my local tree to do an unconditional escape in nsDirectoryViewer. It really makes sense there not to be smart. So clicking on the file with a mouse will work. The current implementation of nsURLEscape/nsURLUnescape trys to be smart. If it finds a % followed by something which can not be converted into a hex number the % is escaped, otherwise it assumes the string is already escaped and does not do anything with the % to avoid multiple escapings. Unfortunally this feature is currently "disabled" (doh!), but I have the fixes in my tree. If the file would have been %XXchimera.html, it would have worked fine.

Jud: Can you review this change for Andreas?

these changes look good to me.

Hmmm ... I don't want to do it this way anymore. I would like to introduce another url-mask for escaping called url_forced, which would switch off smart escaping. This mask would be used in nsDirectoryViewer in addition to the file-urlmask. The current fixes for smart escaping are included in the patches for bug 10736.

I have attached my latest fixes for this bug. It allows %7Echimera to be watched with the DirectoryViewer by switching off smart escaping in this case.

Andreas, will this fix my problem in bug #29653? Do we have a timeline for fixing this? Also: What is the default - "smart" being "on" or "off"? I was very confused by this "feature" and suggest, it is turned of by default.

The default is ON, because it is very bad to escape an already escaped URL. It should stay this way because otherwise many many pages will break. So we try to guess if the string is already escaped, mostly we will get it right, but we will fail in certain cornercases. This is one, foo%bar is another one. This new mask url_forced is for cases where we really know that the string is unescaped. If we don't know that (and that's in most of the cases) we have to guess. It's up to Judson when this goes in. Since it is no PDT+ bug, it may take some more days.

Jud, can you review and check this in, please? Tnx.

I have checked in the fix, marking fixed.

This time for real ...

Broken again, because of rjc's fix to bug 28787. Bug 45966 has also been opened on a similar issue.

-> gagan

This one seems to be fixed a long time ago. The conversion is again done properly. Marking fixed

verified