Last Comment Bug 491807 - Firefox won't open folders with Russian names in new tab or window
: Firefox won't open folders with Russian names in new tab or window
Status: NEW
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: unspecified
: x86 All
: -- major with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
ftp://maxi.selfip.net/pub/
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-06 22:06 PDT by Timur Timirkhanov
Modified: 2009-07-15 22:05 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Timur Timirkhanov 2009-05-06 22:06:05 PDT
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 2009-05-07 11:40:42 PDT
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 2009-07-01 20:29:11 PDT
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 2009-07-02 10:52:39 PDT
(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) 2009-07-15 16:06:48 PDT
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 [:bz] (still a bit busy) 2009-07-15 22:05:30 PDT
> 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....

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