491807 - Firefox won't open folders with Russian names in new tab or window

Status: RESOLVED DUPLICATE of bug 297395

(Firefox :: General, defect)

Description

[Timur Timirkhanov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.10) 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.

Reproducible: Always

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'
Actual Results:  
See an error message "550 CWD failed. <the address of a folder> : no such file or directory."

Expected Results:  
See the contents of a folder

Filezilla, IE and Opera see the content of any folder on the given address

Comment 1

[Alexander L. Slovesnik]

WFM in Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2a1pre) Gecko/20090502 Minefield/3.6a1pre ID:20090502051916

Comment 2

[Timur Timirkhanov]

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.

Comment 3

[Alexander L. Slovesnik]

(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
> Minefield/3.6a1pre
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?

Comment 4

[Michal Novotny [:michal]]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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