Closed Bug 263570 Opened 20 years ago Closed 19 years ago

Can't open a local file which has non-ascii characters in its path/file name

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: asqueella, Assigned: bugzilla)

References

Details

(Keywords: intl, regression)

Attachments

(11 files, 4 obsolete files)

Attachment for Comment #17
429 bytes, text/html
Details
Attachment for Comment #17
455 bytes, text/html
Details
Test file with Japanese filename
117 bytes, text/html; charset=shift_JIS
Details
Firefox Loader .vbs Script - Registry Patch
1.37 KB, patch
Details | Diff | Splinter Review
Firefox Loader .vbs Script
1.19 KB, patch
Details | Diff | Splinter Review
Attachment for Comment #78 bug1
6.64 KB, image/png
Details
Attachment for Comment #78 bug2
6.47 KB, image/png
Details
Windows backslash file separator fix
841 bytes, patch
Details | Diff | Splinter Review
Windows backslash file separator fix. Registry patch
462 bytes, patch
Details | Diff | Splinter Review
Error loading saved local page with russian letter in the file name. Shown only if Firefox is started. If I close all instances of FF and double-click on file, it opened properly.
6.20 KB, image/png
Details
File with Chinese character does not show up in file list.
95.61 KB, image/png
Details 
With a clean profile and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.3) Gecko/20041008 Firefox/0.10
I can't open files that contain cyrillic characters. I get a message, something
like: File /d:/%CB%E5%F0%EC%EE%ED%F2%EE%E2/01.html not found.
I can open files that don't contain non-ascii characters in their path.

On my default profile (net error pages are turned on, open links from ext.
applications set to New Tab) it opens a new tab with an error page and a new
window with the file.

I suppose it is a regression from bug 172962, as it works with 20040924 nightly.
(it opens such files without any problems).

Dan, hope you don't mind the CC. Out of curiosity, you fixed the file://
protocol problems you described in bug 172962 comment 93, right?
>you fixed the file://
>protocol problems you described in bug 172962 comment 93, right?

Yes, but there are some other quirks. I suppose there's no problem if you set
your prefs to open new windows into new windows, is there? This is almost
certainly bug 263689, which I just got around to filing. That bug is caused when
a failure to open the URL aborts the tab creation process. In that bug, the
invalid URL is never successfully opened. It's interesting that in the case of
this bug, the Cyrillic file is successfully opened on its second attempt.

How are you opening the file? Open File Dialog? Double-click from desktop? Drag
and drop from desktop? Something else?
Depends on: 263689
>I suppose there's no problem if you set your prefs to open new windows into new
windows, is there?
I experience the same problem even if I set everything to open links from Other
applications in New windows (everything else is default). So I assume it is
different (though probably related) from bug 263689.

Drag'n'drop and File>Open works correctly. Everything else doesn't - shortcut
from desktop, html file from explorer or from Total Commander. 

[When I tried to open an http://cyrillic.ru link from TB (I suspect this is not
supported, but still) - it resulted in a *very* strange link in the URL bar
(http://www.xn--b1agh1afp.ru/), and no second window was opened.]
Nickolay, does the machine you're using primarily use a Western character set
with Cyrillic fonts added? Or is it primarily a Cyrillic machine? Or does that
make any sense? I know very little about un-American machines :)

Darin, is it possible that all Cyrillic URLs fail their first attempt to load,
causing us to realize there's a problem and try again with a nsIURIFixup-ed
version of the URL, which succeeds? (If so, hopefully that's true only on
primarily Western machines.)
I have non-translated version of Windows (I believe this means "primarily
Western") installed but everything in Regional and Language options is set to
Russian. It has cyrillic keyboard layout, if that matters.
hmm... looking at:
https://bugzilla.mozilla.org/attachment.cgi?id=159445&action=view
+            ios->NewURI( urlStr, 0, 0, getter_AddRefs(uri) );

(which should maybe use NS_NewURI)

urlStr looks like it is probably not UTF-8 encoded. maybe this causes the
problem.  might be better to just nsEscape it before passing to the ioservice...
*** Bug 268440 has been marked as a duplicate of this bug. ***
*** Bug 269044 has been marked as a duplicate of this bug. ***
*** Bug 269040 has been marked as a duplicate of this bug. ***
*** Bug 268955 has been marked as a duplicate of this bug. ***
Lot of dupes now with FF 1.0 for other non-ascii chars.
Summary: Can't open a local file which has cyrillic characters in its path → Can't open a local file which has non-ascii characters in its path/file name
sorry, forgot to mention that it seems the bug appears only if a) file with
non-ascii chars in name/path is opened from shell/explorer and b) FF is already
running
*** Bug 269350 has been marked as a duplicate of this bug. ***
I'm pretty sure this is a ___ of the interconnected bug 162361 and bug 239279,
but I can't quite figure them out well enough to say if the blank should be
filled in with dup or depends.
Perhaps I should have specified in my report that this was a new bug for me when
I upgraded to the recent Firefox 1.0.

This bug did NOT manifest for me with the prerelease when loading files from a
directory with the '²' (unicode 0x00B2) character.  With the recently released
Firefox 1.0, this bug does manifest.  I don't know about cyrillic or other
non-ascii characters - but with that one, it worked in the prerelease and not in
1.0.

*** Bug 269718 has been marked as a duplicate of this bug. ***
I suggest increasing the severity because this bug means that all users of
Japanese Windows cannot open files downloaded to the desktop because the desktop
folder is in Japanese. Other international versions of windows may also apply.
For me opening a file with non-ascii characters (german ae umlaut) via "Open
File..." works.
But if I have a file which contains a link to such a file Firefox tells me that
the file cannot be found.
I have an english Windows XP.

I'll create an attachment for this bug containing two test files: "test.html"
and "ärger.html" (the file with the german ae umlaut"). Directly opening the
"ärger.html" file works but opening it with the link in "test.html" doesn't work.
*** Bug 270282 has been marked as a duplicate of this bug. ***
Don't know if bugzilla supports this, but I'll try to attach a Japanese html
file. Downloading this and opening it by doubleclicking it should easily
reproduce the bug.
This bug seems to extend to other products, including Mozilla Calendar.  When
the calendar (.ics) files are in my Windows "home" dir (C:\Documents and
Settings\Roberto Ordóñez\...), Calendar can't open them.  If I put them in a
path with no non-low-ASCII characters, they're fine.  AAARGH!

This is a serious i18n issue--please raise its priority/severity!  It makes
these otherwise EXCELLENT products almost unusable if you use any non-US-English
characters in pathnames!
Severity: normal → major
*** Bug 270402 has been marked as a duplicate of this bug. ***
What's the rule, then? A URI (whose origin was a string passed in by the
system) spends a moment as a string in this code before it becomes a URI again.
It's an issue with requirements of different downstream APIs. un/escaping seems
to be automatic everywhere except at this step.

I have confirmation from Nickolay (thanks!) that this patch fixes this bug. All
this bug's duplicates would probably also fall to this patch, but I think
comment 17 is something else entirely.
Attachment #166365 - Flags: review?(darin)
*** Bug 271003 has been marked as a duplicate of this bug. ***
*** Bug 271169 has been marked as a duplicate of this bug. ***
Comment on attachment 166365 [details] [diff] [review]
the un/escape dance is a two-step

What is the nature of this URL spec?  Do you know that it is really ASCII after
unescaping?  In general, it is a bad idea to unescape random URL strings
because you don't know how the unescape characters are encoded.  (e.g., is it
Shift-JIS?, ISO-8859-1? or what?  only the server knows.)

If you are sure that this is ok, then no problem, but I suspect this could lead
to problems.  Of course, it's possible that any bytes will just be treated as
ISO-8859-1, inflated to UTF-16 that is no problem, and then deflated again at
some point.  Is that what you are betting on?
In general, the only time we should ever need to unescape a file:// URL is when
converting it from a URL to a nsIFile, and that all happens down in the depths
of necko (see NS_GetFileFromURLSpec).

Are you sure there isn't a better way to solve this problem?
*** Bug 271506 has been marked as a duplicate of this bug. ***
give some information abot this bug:
FireFox 1.0PR has no this bug;
FireFox 1.0 has it. 
Maybe someone can diff them? :-)
This too allows the opening of local files with path/names that Mozilla wants
to escape, and addresses Darin's misgivings in comment 28.
Attachment #166365 - Attachment is obsolete: true
Attachment #167453 - Flags: review?(darin)
Comment on attachment 167453 [details] [diff] [review]
special-case creation of local file URI

>Index: toolkit/xre/nsNativeAppSupportWin.cpp

>+          nsCOMPtr<nsIFile> file( do_QueryInterface ( localFile ));

This QI is unnecessary since nsILocalFile "is a" nsIFile.

Otherwise, this patch looks great.

r=darin with the QI removed.
Attachment #167453 - Flags: review?(darin) → review+
Neat-o. Needs testing and possible similar patches on other platforms, so I'll
probably be bugging you for a real review after I have a chance to borrow some
hardware again. And once again the case in comment 17 remains unaddressed --
looks like there's a similar error in maybe docshell that might want to be
rolled in.
Attachment #166365 - Flags: review?(darin)
Bugs which possibly relates to the problem ;
 (1) Bug 261934
     regression: network.standard-url.encode.utf8 pref is ignored
 (2) Bug 267980
     URL with german characters not parsed correctly when protocol file:/ missing
Bugs which maybe relates to the problem in some cases ;
 (3) Bug 234878
     Escape code issues in URL launching
 
*** Bug 275013 has been marked as a duplicate of this bug. ***
(In reply to comment #34)
> Bugs which possibly relates to the problem ;
>  (1) Bug 261934
>      regression: network.standard-url.encode.utf8 pref is ignored
>  (2) Bug 267980
>      URL with german characters not parsed correctly when protocol file:/ missing

 I don't think those two bugs (both suite and firefox have those problems) are
related with this bug. This bug is firefox-specific and Mozilla suite doesn't
have a problem with double-clicking in windows explorer. 

Actually, the other aspect of this bug is not firefox specific (comment #17) nor
a regression. The suite has the same problem.
Keywords: intl
*** Bug 275147 has been marked as a duplicate of this bug. ***
*** Bug 275676 has been marked as a duplicate of this bug. ***
*** Bug 267430 has been marked as a duplicate of this bug. ***
I've just tried suite and firefox on Linux (UTF-8 locale) and Mac OS X. Both
don't have any issue with two problems dealt with here. Under a non-UTF-8 locale
on Linux, it may have a problem and there are some variations of test cases I
have yet to test. I'm rebuilding firefox trunk on Windows after distclean
(somehow xpcom got screwed up and I couldn't test) to see if attachment 167453 [details] [diff] [review]
works.

 
Comment on attachment 166174 [details]
Test file with Japanese filename

next time you upload a Japanese html file, please add charset paramer in MIME
type and/or add 'meta tag' for charset specification.
Attachment #166174 - Attachment filename: テスト.html テスト.html → ¤Ô¤¡¤Ò¤®¤Ô¤¡¤Ò¤¦¤Ô¤¡¤Ò¤°.html ¤Ô¤¡¤Ò¤®¤Ô¤¡¤Ò¤¦¤Ô¤¡¤Ò¤°.html
Attachment #166174 - Attachment mime type: text/html → text/html; charset=shift_JIS
> But if I have a file which contains a link to such a file Firefox tells me that
> the file cannot be found.

In 'about:config', can you check the value of
'network.standard-url.encode-utf8'? It is false by default, but it seems like
it's set to true in your case. With that set to false, I cannot reproduce the
problem on Windows. See also bug 261929. Btw, you also have to make sure that
the character encoding of your html file refering to a local file with non-ASCII
name is set correctly. 





(In reply to comment #42)
> > But if I have a file which contains a link to such a file Firefox tells me that
> > the file cannot be found.
> 
> In 'about:config', can you check the value of
> 'network.standard-url.encode-utf8'? It is false by default, but it seems like
> it's set to true in your case. With that set to false, I cannot reproduce the
> problem on Windows.

In case of html, jpg, png, etc, it works fine. However, if it's a windows media
file (especially specified in object tag) that should be handed over to a WMP
(pluggin), there's a problem. 
Comment on attachment 167453 [details] [diff] [review]
special-case creation of local file URI

asking for sr

Phew, it took me more than a day (somehow my build didn't start even after
several distclean/rebuild cycles). Attachment 167453 [details] [diff] (sans the unnecessary
QI'ing) works fine for double-click-to-open.

The issue in comment #17 (with standard-url.encode-utf8 set to true) had better
be dealt with in another bug, IMO. Yet another problem 
(comment #43) is likely to have  been already reported
Attachment #167453 - Flags: superreview?(bryner)
NS_NewURI wants an UTF-8 string - is args (urlStr) utf-8 encoded?
(In reply to comment #45)
> NS_NewURI wants an UTF-8 string - is args (urlStr) utf-8 encoded?

I believe so (more likely to be just ASCII) because it's coming from browser.js
(see attachment 166365 [details] [diff] [review]). Otherwise, coming across XPconnect boundary, I'd have
gotten an assertion fired when I tried it.



but... if it's UTF-8, then won't the NewNativeLocalFile do "the wrong thing",
when the FS charset is != UTF-8?
*** Bug 277058 has been marked as a duplicate of this bug. ***
*** Bug 277692 has been marked as a duplicate of this bug. ***
When I open via File-Open or DragAndDrop a file named "D:\test\&#916;&#959;&#954;&#953;&#956;&#942;.html" then
Firefox address bar shows "file:///D:/test/%C4%EF%EA%E9%EC%DE.html". Wouldn't be
better the address bar would show the original greek charackter encoded in utf8
and not convert them to %C4 etc?

Also I noticed in my system (WinXP-SP2 international and all regional options
set to Greek) I can't open a file named with cyrillic characters for example
"D:\test\&#1072;&#1090;&#1092;&#1099;&#1091;&#1084;&#1090;.html". Firefox says that it cannot find file
D:/test/???????.html. It replaces all cyrillic charackter with ?. I tried double
click, File-Open, DragAndDrop but firefox can't find the file. That looks like a
very serious bug.




Sorry wrong encoding... I switched to utf-8

When I open via File-Open or DragAndDrop a file named "D:\test\Δοκιμή.html" then
Firefox address bar shows "file:///D:/test/%C4%EF%EA%E9%EC%DE.html". Wouldn't be
better the address bar would show the original greek charackter encoded in utf8
and not convert them to %C4 etc?

Also I noticed in my system (WinXP-SP2 international and all regional options
set to Greek) I can't open a file named with cyrillic characters for example
"D:\test\атфыумт.html". Firefox says that it cannot find file
D:/test/???????.html. It replaces all cyrillic charackter with ?. I tried double
click, File-Open, DragAndDrop but firefox can't find the file. That looks like a
very serious bug.

(In reply to comment #51)

> Also I noticed in my system (WinXP-SP2 international and all regional options
> set to Greek) I can't open a file named with cyrillic characters for example

That is bug 162361. 

*** Bug 279110 has been marked as a duplicate of this bug. ***
Comment on attachment 167453 [details] [diff] [review]
special-case creation of local file URI

Recent changes in the command line handler made this patch obsolete. I thought
it might have fixed this problem, but we still have the same issue with a
little different symptom.
Attachment #167453 - Attachment is obsolete: true
Attachment #167453 - Flags: superreview?(bryner)
The toolkit clh? I tried to make it handle commandline args in a
charset-sensitive way. Is there something broken in the "core"?
The first time I tried my build with the new command line handler,
double-clicking on a file with non-ascii path/name with no firefox window
present didn't work. The way it failed was very curious. I tried to open a file 
'가나.html' (set the encoding to UTF-8 to view this comment) on the desktop and
got three alerts. The first one complained that it couldn't find a file
'C/Documents' and following two alerts complained about 'C:\Documents and
Settings/jungshik/Desktop/' and 'C:/Documents and Settings/jungshik/Desktop/가
나.html', respecitvely. 

However, after quitting my debug build and trying it again,
it worked !! I don't understand this, but ....I'll try more. 

The issue in comment #17 will be dealt with in bug 278161 (see also bug 263570).
If the the pref. related with url encoding is set to the old default (which was
false), the problem will be gone. However, it should be set to true for external
urls  so that I'm gonna deal with it in bug 278161.
*** Bug 281162 has been marked as a duplicate of this bug. ***
*** Bug 281508 has been marked as a duplicate of this bug. ***
*** Bug 281564 has been marked as a duplicate of this bug. ***
Bug is still apparent in Firefox 1.0.1.

I don't have the bug anymore.
I can open files that have greek and latin characters on my english windows XP
with regional options set to greek.

All I did was to go to Control Panel > Folder Options > File Types > HTML file >
Edit > and chance the command to C:\PROGRA~1\MOZILL~1\FIREFOX.EXE -url file://"%1"

That is I just added file://

Way to easy so I guess it should have been reported somewhere already but at
least now I can have firefox open my local files without problem 
Use with caution. I am not sure if at your PC C:\PROGRA~1\MOZILL~1\FIREFOX.EXE
is the executable path to firefox. Use file run to verify and edit accordingly
*** Bug 283986 has been marked as a duplicate of this bug. ***
(In reply to comment #61)
> That is I just added file://

I did that, too. Now I can open these files, but images aren't shown. If I drag
& drop the file to Firefox the images are shown.
Attached patch Firefox Loader .vbs Script (obsolete) — — Splinter Review 
This vbs does the trick that my previous registry patch did but also replaces \
with /. So C:\test.html will become C:/test.html. Strange definetely but now
firefox loads correctly the local html's. Please test a lot to see that
everything works OK even in complex html with external CSS etc.

I will also post a registry patch for your convenience.
Attachment #175757 - Attachment is obsolete: true
So here is the registry patch.

Install Instructions:
I assume you have kept the defaul mozilla firefox install directory (C:\Program
Files\Mozilla Firefox).
Also you need Windows Scripting Host. If you have XP I guess you have it
already.
Drop "firefox loader.vbs" in "C:\Program Files\Mozilla Firefox"
Apply the "FirefoxHTML.reg"
You are ready.
I had icluded a FileSystemObject in the original script that was not needed so
here is it without it.

By the way I tested it on many "complex" html files (with external CSS etc) I
have saved from internet and all open fine without problems.
Attachment #175776 - Attachment is obsolete: true
This fix/patch seems to work on Unicode Chinese file names, but doesn't work for
Big5 Chinese file names. The symptoms after applying Firefox Loader.vbs patch
for opening a file named C:/My Documents/¿i¥É¦æ.html (Big5 Chinese) will open
Firefox showing a page titled
Index of file:///C:/My Documents/???.html
then the list of files in C:/My Documents, without any file names containing
Big5 Chinese characters; i.e. the usual directory listing.

Try opening JPEG files with Big5 Chinese file names using Firefox doesn't work,
either. Firefox opens with alert "The file C:/My Documents/¥É.jpg cannot be
found. Please check the location and try again." and black page.
(In reply to comment #68)
I know what you mean. In my Engish Windows XP I have set all regional options to
Greek. Before I created this script I could only open latin filenames. Now I can
open both greek and latin filenames. But when I try to open a cyrillic filename
I can't and have the same as you. On the other hand I haver never used cyrillic
file names.

From what I understand you are trying to open a file with a filename with
different characters than the ones you have set in your regional options. I
don't think it's possible to solve that with a script.

What you ask seems more like <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=162361">Bug 162361 Unicode
file i/o in XPCOM/IO</a>

My scipt is useful to people that use latin and one more alphabet defined in
regional options.
kronosk9981@hotmail.com is right. After I change my regional options to Big5
Chinese, Firefox can open filenames in Big5 Chinese. JPEG with Big5 Chinese
filenames still don't open.

What I really want is more like <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=162361">Bug 162361 Unicode
file i/o in XPCOM/IO</a>.
(In reply to comment #70)
You should associate .jpg with "firefox loader.vbs" like the html files and not
with firefox.exe. Then they have the same behavior as the html files.
The easiest way to avoid this problem is:
1.Run: regedit
2.Open Key: HKEY_CLASSES_ROOT\FirefoxHTML\shell\open\command
3.Change 'Default' to 'C:\PROGRA~1\MOZILL~1\FIREFOX.EXE -url "file://%1"'. 

Yes, add "file://" before "%1".

4.Try open html files again.
Sorry for the previrous post ... ...

Though FireFox can open the html file, it cannot open other resources that
needed by the html file(such as css, images, javascript, and so on). So it
cannot render the html correctly.

How let FireFox not encode "\" to "%5C"? Maybe this can solve the problem ... ...
*** Bug 286116 has been marked as a duplicate of this bug. ***
I would like to also agree that this is a pretty nasty problem and I would 
love to see this fixed. I filed defect 286116 yesterday that was duped against 
this bug. It gives some pretty detailed examples of the crazy behavior, i was 
seeing if that helps any (possibly test cases for fix :D )
I don't mean to complain (usually I'm a 'put up or shut up' person), but surely
this bug can't be rocket science to quash.  The developers do know that the last
prerelease did /not/ have this bug... right? It was the first "final" release
where it showed up.  Was there that much that changed between the prerelease and
the final release that a diff of the two won't catch it?
*** Bug 287505 has been marked as a duplicate of this bug. ***
I think you are talking about 2 different bugs.

Bug 1
a) First appear in final version of Firefox 1.0.
b) Only if the browser is already open.
c) The bug happens if the file is open with the Windows file explorer. (Not with
the File menu of Firefox.)
d) Example: "Mes téléchargements" folder.

Bug 2
a) Was already present and exist in Mozilla too.
b) Happen even if the browser is closed. 
c) The bug happens even if the file is open with the File menu (of Firefox or
Mozilla).
d) Example: Japanese characters.



    
    

    
  


  

    
    

    
  
Firefox 1.0.2, Windows 2000 + SP4. And I have "a new tab in the most resent
window" setting enabled in "advanced" section of options.

If I have a browser window already open and I click a file with "strange"
characters in it's name, as already pointed out the file won't open to a new tab
and it will give the error message.

But I think no-one pointed out that a new tab is opened in the browser window,
the thing is, it is empty and you can't close it any other way, except by
closing the whole window, or by adding another tab and then closing it. Somehow
the tab with error seems to get locked. The tab should close if user selects
close from the tab menu or if user presses the red x on the corner.

    
    

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

    
    

    
  
(In reply to comment #3)
> Nickolay, does the machine you're using primarily use a Western character set
> with Cyrillic fonts added? Or is it primarily a Cyrillic machine? Or does that
> make any sense? I know very little about un-American machines :)
> 
> Darin, is it possible that all Cyrillic URLs fail their first attempt to load,
> causing us to realize there's a problem and try again with a nsIURIFixup-ed
> version of the URL, which succeeds? (If so, hopefully that's true only on
> primarily Western machines.)

I have the same problem with win2000, all SP, all English.
Firefox 1.0.1 (both russian and english) cannot open local files with russian
names from russian folder names, files and folders are visible from window, but
at the last step it says "no such file or directory".
IE can open such files.

The issue is probably critical for ALL non-native english speakers in US.
So we have to use IE, not firefox, period. 


    
    

    
  
The bug as I have reported it no longer appears on trunk. Could someone from
developers summarize why this is still open?

Everybody, please don't add comments, unless you have something *new* to say.
Read <http://bugzilla.mozilla.org/page.cgi?id=etiquette.html> for more info.

    
    

    
  
i found another related problem.

if you try to open more than 1 file at once with cyrillic pathname, you will get
only 1 file opened. doesn't matter in this case if firefox was already opened or
not.

i have also fixed registry using instructions in comment #61. (and it worked
well in single file opening)

to reproduce problem close all firefox windows. select several files with
cyrillic  filenames, and then hit ENTER key, you will get only 1 file opened.

I don't know probably it is a new bug or a duplicate of existing bug.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  


  
Windows backslash file separator fix

This JS script changes Windows backslash file separator to slash one to allow
firefox load local html files.
It only requires java script to be enabled in firefox. No other software
needed.

I will also post a registry patch for your convenience.

    
    

    
  


  
Windows backslash file separator fix. Registry patch

This reg file changes file open command so Firefox open files using backslash
file separator fix JS script
(see comment #90)

    
    

    
  
I just want to add the comment that this problem also is very real on LINUX 
flavors as well. I see a lot of windows attention being given to this defect, 
and want to just iterate that linux flavors also need to be tested as well, 
when a fix is finally available. 

    
    

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

    
    

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

    
    

    
  
I cannot open local files using double-click when files' names include chinese
character.
and when "save as..."，the link in the html is changed to be "<img
src="Session%CF%EA%BD%E2----_files/index_03.jpg"， ie cannot recognize it.

    
    

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

    
    

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

    
    

    
  
Please change the OS to All. Linux and Windows NT is affected as well.

    
    

    
  
I'm the original reporter and this works for me (for a long time; using trunk
build, not 1.0). There are a few different issues here, and it's not clear who
is experiencing what.

I would appreciate if a developer (jshin? danm?) explained why this is kept open
(i.e. what issues are not yet addressed, but should be in *this* bug). I would
also appreciate that people don't add even more
confirmations/screenshots/related problems here. Thanks in advance.

    
    

    
  
This bug is  about Chinese file name can't bolt open in windows explorer
(In reply to comment #0)
> With a clean profile and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.7.3) Gecko/20041008 Firefox/0.10
> I can't open files that contain cyrillic characters. I get a message, something
> like: File /d:/%CB%E5%F0%EC%EE%ED%F2%EE%E2/01.html not found.
> I can open files that don't contain non-ascii characters in their path.
> 
> On my default profile (net error pages are turned on, open links from ext.
> applications set to New Tab) it opens a new tab with an error page and a new
> window with the file.
> 
> I suppose it is a regression from bug 172962, as it works with 20040924 nightly.
> (it opens such files without any problems).
> 
> Dan, hope you don't mind the CC. Out of curiosity, you fixed the file://
> protocol problems you described in bug 172962 comment 93, right?

    
    

    
  
(In reply to comment #101)
> This bug is  about Chinese file name can't bolt open in windows explorer

On non-Chinese Windows? No, it's not. see comment #52, please.

I'm building a trunk build and see if things have gotten better (see comment #56)


    
    

    
  
I confirmed that it's fixed (see comment #54, comment #55, comment #56 and
comment #100) by bsmedberg's command line handling fix. The issue in comment #17
is dealt with in bug 278161. For issues with Greek /Russian file names on
French/English Windows (and many other variants), see bug 162361 (and please,
don't add any more comment here)

Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
(In reply to comment #103)
> I confirmed that it's fixed (see comment #54, comment #55, comment #56 and
> comment #100) by bsmedberg's command line handling fix. The issue in comment #17
> is dealt with in bug 278161. For issues with Greek /Russian file names on
> French/English Windows (and many other variants), see bug 162361 (and please,
> don't add any more comment here)
> 

So what attachment do I need to download to fix this for Japanese or will the
patch be in 1.0.6? This is still happening in 1.0.5 and bugs the hell out of me.

    
    

    
  
> So what attachment do I need to download to fix this for Japanese or will the
> patch be in 1.0.6? This is still happening in 1.0.5 and bugs the hell out of me.

Version numbers x.y.z tell you that 
x is for very major changer
y is for major changes
z is for security updates

So you won't get this fixed in 1.0.6 or any of 1.0.z versions. Try latest
nightly build, alpha 2, or wait for 1.1.0 beta, RC or final version.

    
    

    
  
(In reply to comment #110)
> > So what attachment do I need to download to fix this for Japanese or will the
> > patch be in 1.0.6? This is still happening in 1.0.5 and bugs the hell out of me.
> 
> Version numbers x.y.z tell you that 
> x is for very major changer
> y is for major changes
> z is for security updates
> 
> So you won't get this fixed in 1.0.6 or any of 1.0.z versions. Try latest
> nightly build, alpha 2, or wait for 1.1.0 beta, RC or final version.

Ok, is there a patch attached here I can download and use? and not have to wait
months for 1.1 to come out

    
    

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

    
    

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

    
    

    
  
I just tested this and I still/again have the problem with todays Deerpark Alpha
2 nightly. A file with a Chinese character does not show up in the view of the
local directory (Win2K-English). See attachment.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050727 mrcl
(w) Firefox/1.0+

    
    

    
  
(In reply to comment #115)
> A file with a Chinese character does not show up in the view of the
> local directory (Win2K-English). 

I think that is a different Bug #162361

    
    

    
  
As an addition to comment 115: I also get this message when I double click the
file from Windows Explorer:

"File Not Found Error

The file /C:/Documents and Settings/etmvabe/My Documents/My Skype Received
Files/1521?size.jpg cannot be found. Please check the location and try again.

The file specified by the address (URL) cannot be found. Check that the file
exists and that you have sufficient permissions to view it."

So I was just wondering what was exactly resolved with this bug.


    
    

    
  
(In reply to comment #117)

> So I was just wondering what was exactly resolved with this bug.

For example I have Finnish language version of Windows and now if I open a file
that has characters on Finnish charset, those files open correctly with Deer
park Alpha 2, while they don't open correctly with Firefox 1.0.6. So that is
what is fixed and that is the reason why this bug is fixed.

The other bug I mentioned previously is about opening files that contain
characters outside of the operating system charset (for example Chinese
characters on English-version of Windows). Which I think is the case with you.
And that bug is still not fixed.

    
    

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

    
    

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

    
    

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

    
    

    
  
On my Windows Xp no images,stylesheets or other relative resources are loaded
unless the backslashes (%5C) when opening a local file are replaced with slashes
(/) in the adress bar. 

Therefore 
<img src="./test.jpg"> 
in file:///C:%5Ctest.htm wont be opened, but in file:///C:/test.htm it will.

This makes the whole thing worthless on Windows, I'm really wondering why this
bug hasn't been fixed yet..

    
    

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

    
    

    
  
(In reply to comment #122)

> This makes the whole thing worthless on Windows, I'm really wondering why this
> bug hasn't been fixed yet..

Have you tried a trunk build available at
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk ?




    
    

    
  
> This makes the whole thing worthless on Windows, I'm really wondering why  
> this bug hasn't been fixed yet..  
  
Yeah, the bug in Windows users who assume that file URLs are supposed to have  
backslashes in them, is a long-standing one which will probably never be fixed.  

    
    

    
  
The problem is that windows uses the standard of \ instead of / as A filename,
so If Any file is opened with firefox it screwes up, since firefox serves the
service of opening local files itself it should recognise that problem for
Windows users.

Fact is that on windows backslashes ARE served by windows if you tell it to open
a file with a program, that is a thing I can't change. As the file:// function
generally works on windows and the file associations are set by firefox it
should also work with the standard way files are opened with - or just not port
the feature to windows, but opening the file despite the backslashes, but not
any external files containing relative references sucks. 

By the way - when was this fixed? - I'm using 1.0.6 and it does not work at all... 

    
    

    
  
(In reply to comment #126)

> By the way - when was this fixed? - I'm using 1.0.6 and it does not work at
all... 

Unless it's noted differently, 'resolved fixed' means that it's fixed on the
trunk (as opposed to any branches like 1.0.x). See comment #124. It's NOT fixed
on 1.0.x. If you don't wanna try a nightly, you can try DeerPark 1.1alpha2. 





    
    

    
  
I am now working with DeerPark (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.8b3) Gecko/20050712 Firefox/1.0+). Some aspects of this bug still exist in
DeerPark, makes it worse than in Firefox 1.0.x. You may want to reopen this bug
as a regression bug.
I have a page with charset windows-1255, with a link to a non-ASCII7 file. When
trying to follow the link, DeerPark fails to open the url as it is trying to
open the UTF8 encoding of the url rather than the FS-encoding of the URL. In
fireox 1.0.x, it opened the url without any problem.
Also openning non-ASCII7 files from the directory listing ("index of ...")
doesn't work in DeerPark for the same reason.


    
    

    
  
Zvi: that's not what this bug was about. This is about opening files from other
applications. Your bug is about opening files through a link from another
webpage. Please look if your bug is already reported, and if it isn't, please
file it separately.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
Is this a regression? Tested with FX 1.5.0 on Windows XP French, foreign characters turn into question marks (%3F) in the address bar when trying to drag and drop a file or via the commandline, and they turn into underscores when trying to open via File>Open File.

See also 111428, 174734, 235495 for bookmark-related bugs that exhibit the lack of proper support for files with foreign filenames.

    
    

    
  
(In reply to comment #140)
> Is this a regression? Tested with FX 1.5.0 on Windows XP French, foreign
> characters turn into question marks (%3F) in the address bar when trying to

No, this bug is not about file names with characters NOT covered by the current ANSI codepage (e.g. Chinese characters in French Windows) but about non-ASCII characters *covered* by the current ANSI code page (e.g. Latin letters with diacritic marks in French Windows). See bug 162361 for your problem and bugs depending on it. I've been working on bug 162361.

    
    

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

    
    

    
  
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070730 SUSE/2.0.0.6-10.1 Firefox/2.0.0.6

The bug appears to be back. Firefox crashes when trying to open
http://www.cafeoflifepikespeak.com/Videos/Licensed%20To%20Pill.swf

The file crashes firefox everytime. I can download the file and play it in konqueror without problems, but even if I rename the file to remove the %20 the file still crashed firefox. See:

http://www.3111skyline.com/Licensed_To_Pill.swf

This might be a firefox/shockwave issue.



    
    

    
  
David: that issue seems entirely unrelated to this bug?

    
    

    
  

Not knowing more, the non-ascii problem looked related. I agree that if it is a pure shockwave problem, then this bug is irrelevent. Just thought I would post here before you had to expend the effort to tell me it was a duplicate. I'll search further.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: