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?

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

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!

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

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

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.

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.

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.

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

> 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

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.

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.

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.

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.

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)

Checked in 1.0.3

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)

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