User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9) Gecko/2008052906 Firefox/3.0 OS: Windows XP Tranditional Chinese Edition Reproducible: Always Steps to Reproduce: 1. Search "花店" in Google Search from search box on the top-right of Firefox 2. All things go well till now. 3. Locate your cursor into location bar, hit enter to "Go to link" 4. URL in location bar changed and turned "花店" to "%xx%xx" utf encoding. 5. The results in Google Search is corrupted. 6. But if you just use www.google.com/?q=花店, there is no such problem. Same problem happens when using some search from Yahoo! Taiwan: 1) http://tw.search.yahoo.com/search/kp?fr=ffds1&p=花店 will turn into http://tw.search.yahoo.com/search/kp?fr=ffds1&p=%AA%E1%A9%B1, and the search result is corrupted characters. 2) http://tw.dictionary.yahoo.com/search?fr=ffds1&ei=utf-8&p=花店 3) http://www.google.com.tw/search?q=花店&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:zh-TW:official&client=firefox This only occurs on Windows XP&Vista (Traditional Chinese Edition) We don't have a screenshot software, so take some pictures
Screenshot-capturing functionality is built in to Windows -- just use either ALT+Print Screen (PrtScn) or just PrtScn by itself: http://graphicssoft.about.com/cs/general/ht/winscreenshot.htm
Thank you. And how to do that on a MacBook Pro box which using BootCamp to start a Windows, :)
Command+Shift+4, with spacebar to toggle modes should work
This bug seems only reveal itself when "network.standard-url.encode-query-utf8" in about:config is set to "false", which happened to be the default setting. In a Big5 query web page, all query are automatically transformed into %xx at the first place (step 2 in comment 1).
After some testing, I am pretty sure it is related to the pref mentioned above; according to bug 333859 comment #2, query string will be sent using system charset when it is typed directly. It seems changing the input string, or simply press enter again on the location bar is equivalent to typing the URL directly. The simplest fix for this one would be the same as bug 333859 - let's set the pref to true to default. I am going to set bug 333859 blocks this bug.
Let me rephrase my proposed solution: A) Fix bug 333859 (preferred), always send query strings in UTF-8 when inputed directly. B) Fix how location bar represent the URL with a CJK query string (that is sent with UTF-8). It should escape the CJK characters when the pref is false, which another [enter] would result the characters being sent as system encoding. Or we should do (A) as a workaround, and (B) for the fix. I would with this bug being fixed as soon as possible, as this had annoyed zh-TW Windows users for many many years probably since the Awesomebar has introduced.
http://hg.mozilla.org/l10n-central/zh-TW/rev/cc7924e17ee0 Setting network.standard-url.encode-query-utf8 as true in zh-TW repo as zh-TW users feel greater impact by this bug.
http://hg.mozilla.org/l10n-central/zh-TW/rev/d6e4ed7cc531 Minor syntax fix for previous push
Why do we need to add this to localized preferences now? As long as bug 333859 isn't fixed due to bad side-effects, I'm not convinced that these should be ignored for one locale.
... because that one locale takes the heaviest impact of bug 333859? Unless the behavior stated in (B) is being fixed, it's justifiable. Bug 333859 comment 9 said it's too risky to turn on, yet for Taiwanese website that mostly use UTF-8, it's too risky to leave it off.
confirmed on windows 7, affects facebook and wikipedia. this affects japanese websites as well. flipping switch doesn't affect English sites, and brings this in line with the URI directory part. shouldn't this be applied to mozilla-central instead of l10-central?
Isn't this a duplicate of bug 461304?
Bug 461304 will not fix "changing the input string" case.
Fixed by bug 647403.