Steps to reproduce: 1. Create a file named "a　.exe". 2. Drag the file and drop to Firefox. Actual Result: Firefox will save the file to a%u3000.exe. Expected Result: Firefox will save the file to "a　.exe".(U+3000 is reserved.) I can reproduce Recent Nighlty build with Linux and Windows 8.1. This bug is reported to bugzilla-jp as http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=6914.

Regressed since Firefox36. Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=992784f79f96&tochange=f884c46fa07d Triggered by Bug 415491

Reproduce with SeaMonkey-nightly/win32 . User agent: Mozilla/5.0 (Windows NT 5.1; rv:37.0) Gecko/20100101 Firefox/37.0 SeaMonkey/2.34a1 Build identifier: 20141208003001

Reproduce with Thunderbird38.0.1 Steps to reproduce: Click on the attached file name, and choosing a "save the file". Press "save"icon or bottom attached file name are no problem.

Correction: Press "save"icon or click bottom attached file name and select "save" are no problem. Click bottom attached file name and select "open" are reproducible.

Windows7, Windows8.1, Mac OS X 10.10 are reproducible. Reproduce when the "Opening [filename]"window is opened. Does not reproduce if you save without opening "Opening [filename]"window. Both Attachment 8624164 [details] and 8624170's blue frames(reproduce), "Opening [filename]"window opens when you want to save. Please see below Mozillazine.jp's thread. http://forums.mozillazine.jp/viewtopic.php?f=3&t=15474

This seems to be related: when displaying <a href="#%CC%B7"> the status bar displays "#%u0337". The character is displayed correctly in the address bar when the link is clicked, but window.location.hash contains the "#%u0337" too.

Still reproduced on Tb 52.0a1.

This also reproduces on Fx 52.0a1. How to reproduce: 1. Put file with name of "sample　sample.docx" at local machine 2. Open URL for the file location (ie. file:///C:/Users/foo/Desktop/) 3. Put mouse cursor on the file name Actual Result: URL shown at the bottom is "file:///C:/Users/foo/Desktop/sample%u3000sample.docx" Expected Result: URL shown at the bottom is "file:///C:/Users/foo/Desktop/sample　sample.docx" I think this is lower level bug than Fx/Tb.

This issue reproduce both Fx and Tb at least. Which product and component is better to reassign?

(In reply to Takanori MATSUURA from comment #9) > This issue reproduce both Fx and Tb at least. > Which product and component is better to reassign? I don't know. It may be core product is better. Does anyone know which product is suitable?

We already allow U+0020 SPACE, so this patch will have no additional risk. I also stopped using Preferences::GetComplex(). Preferences::GetString() will handle non-ASCII prefs correctly.

Comment on attachment 8812423 [details] Bug 1143644 - Allow IDEOGRAPHIC SPACE in UnEscapeURIForUI https://reviewboard.mozilla.org/r/94186/#review94376 ::: intl/uconv/nsTextToSubURI.cpp:241 (Diff revision 2) > > // If there are any characters that are unsafe for URIs, reescape those. > if (mUnsafeChars.IsEmpty()) { > - nsCOMPtr<nsISupportsString> blacklist; > - nsresult rv = mozilla::Preferences::GetComplex("network.IDN.blacklist_chars", > - NS_GET_IID(nsISupportsString), > + nsAdoptingString blacklist; > + nsresult rv = mozilla::Preferences::GetString("network.IDN.blacklist_chars", > + &blacklist); We should use Prefernces::GetString in nsIDNService::prefsChanged too. But we should handle it by another bug.

Pushed by VYV03354@nifty.ne.jp: https://hg.mozilla.org/integration/autoland/rev/bc97fbe7ef27 Allow IDEOGRAPHIC SPACE in UnEscapeURIForUI r=m_kato

Comment on attachment 8812423 [details] Bug 1143644 - Allow IDEOGRAPHIC SPACE in UnEscapeURIForUI https://reviewboard.mozilla.org/r/94186/#review94378 ::: intl/uconv/nsTextToSubURI.cpp:241 (Diff revision 2) > > // If there are any characters that are unsafe for URIs, reescape those. > if (mUnsafeChars.IsEmpty()) { > - nsCOMPtr<nsISupportsString> blacklist; > - nsresult rv = mozilla::Preferences::GetComplex("network.IDN.blacklist_chars", > - NS_GET_IID(nsISupportsString), > + nsAdoptingString blacklist; > + nsresult rv = mozilla::Preferences::GetString("network.IDN.blacklist_chars", > + &blacklist); Oh, we do not even use the Preferences API. Filed bug 1318924.

Can someone from QE verify the fix tomorrow once it's in nightly? Then let's uplift this to at least aurora, maybe beta too.

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #18) > Can someone from QE verify the fix tomorrow once it's in nightly? Then let's > uplift this to at least aurora, maybe beta too. Brindusa, can your team look into this?

Verified as fixed on latest Nightly 53.0a1, Build ID 20161122030216 on Windows 7 and Mac OS X 10.10

Comment on attachment 8812423 [details] Bug 1143644 - Allow IDEOGRAPHIC SPACE in UnEscapeURIForUI Approval Request Comment [Feature/regressing bug #]: 415491 [User impact if declined]: Users (mainly in Japan) will sometimes see garbage in the downloaded file names or some other URL UI. [Describe test coverage new/current, TreeHerder]: Tested manually [Risks and why]: Low. We already allow ASCII spaces in the URL UI, so this change will not add any new spoofing vector. [String/UUID change made/needed]: none

Comment on attachment 8812423 [details] Bug 1143644 - Allow IDEOGRAPHIC SPACE in UnEscapeURIForUI Fix a regression related to download file name. Beta51+ and Aurora52+. Should be in 51 beta 3.