26003 - Files with the percentage (%) sign cannot be viewed via mouse

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[chimera]

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.

Comment 1

[Sean Richardson]

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...

Comment 2

[Gagan]

Andreas do your latest changes fix this?

Comment 3

[Andreas Otte]

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.

Comment 4

[Gagan]

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

Comment 5

[Sean Richardson]

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?

Comment 6

[Andreas Otte]

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. 

Comment 7

[Andreas Otte]

Attachment: patch to do unconditional escaping in nsDirectoryViewer

Comment 8

[Andreas Otte]

Attachment: patch to "turn on" "smart" escaping/unescaping

Comment 9

[Warren Harris]

Jud: Can you review this change for Andreas?

Comment 10

[Judson Valeski]

these changes look good to me.

Comment 11

[Andreas Otte]

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. 

Comment 12

[Andreas Otte]

Attachment: Current fixes for this bug

Comment 13

[Andreas Otte]

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.

Comment 14

[Ben Bucksch (:BenB)]

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.

Comment 15

[Andreas Otte]

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.

Comment 16

[Ben Bucksch (:BenB)]

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

Comment 17

[Andreas Otte]

I have checked in the fix, marking fixed.

Comment 18

[Andreas Otte]

This time for real ...

Comment 19

[Andreas Otte]

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

Comment 20

[Judson Valeski]

-> gagan

Comment 21

[Andreas Otte]

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

Comment 22

[Tom Everingham]

verified