User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:18.104.22.168) Gecko/2009042316 MRA 5.4 (build 02620) Firefox/3.0.10 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; kk; rv:1.9.1b4) Gecko/20090423
If you try to open folders with Russian names in a new tab or a new window, Firefox pops up a error: "550 CWD failed. <the address of a folder> : no such file or directory."
I can also confirm this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090504 as well as with the same versions on Linux.
Steps to Reproduce:
1. Go to the address from URL field
2. Right click on any folder with Russian name
3. Select 'Open in New Window' or 'Open in New Tab'
See an error message "550 CWD failed. <the address of a folder> : no such file or directory."
See the contents of a folder
Filezilla, IE and Opera see the content of any folder on the given address
WFM in Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2a1pre) Gecko/20090502 Minefield/3.6a1pre ID:20090502051916
Unghost, I can STILL see this error message on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090701 Minefield/3.6a1pre and on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090701 Minefield/3.6a1pre
So I think it's worth a review.
(In reply to comment #2)
> Unghost, I can STILL see this error message on Mozilla/5.0 (Windows; U; Windows
> NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090701 Minefield/3.6a1pre and on
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090701
Does it happen with Russian build? Does this error happens if you change network.standard-url.encode-utf8 or network.standard-url.escape-utf8 parameters to true/false?
I can reproduce the bug too. The fix in bug 427089 relys on correct nsIURI.originCharset value. Normally the new URI has correct originCharset value from the referrer URI. But in case of opening link in new tab/window (or even restoring session) the new URI is created without referrer from plain string, originCharset isn't set so the fix don't work. I have no idea if restoring session can be somehow fixed since IMO originCharset isn't stored in sessionrestore.js.
When opening link in a new tab nsDocShell::LoadURI() is called from JS with following stack:
1 loadURIWithFlags() ["chrome://global/content/bindings/browser.xml":186]
2 addTab() ["chrome://browser/content/tabbrowser.xml":1267]
3 loadOneTab() ["chrome://browser/content/tabbrowser.xml":1088]
4 openNewTabWith() ["chrome://browser/content/utilityOverlay.js":566]
5 openLinkInTab() ["chrome://browser/content/nsContextMenu.js":625]
We have the originCharset and referrer in openNewTabWith() and above so one possible solution is to set URI's originCharset somewhere here. I'm not sure if this can break something and if it is an acceptable hack.
> I have no idea if restoring session can be somehow fixed since IMO
> originCharset isn't stored in sessionrestore.js.
_That_ could be fixed. So could the broken URI-creation behavior when opening a new tab or window. And not only could, should. Moving this bug to Firefox UI; please file a new bug on sessionrestore? Note that if sessionrestore were storing URIs via nsISerializable instead of as strings (gah!), this would all work....