Closed Bug 552273 Opened 15 years ago Closed 12 years ago

default network.standard-url.encode-query-utf8 breaks major websites

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla28

People

(Reporter: henry.fai.hang.chan, Assigned: hsivonen)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 Build Identifier: default network.standard-url.encode-query-utf8 breaks major websites for example facebook and wiki (older versions). Reproducible: Always Steps to Reproduce: Go to http://www.facebook.com/search/?q=肥婆成身都是脂肪 Actual Results: Resolves to http://www.facebook.com/search/?q=%AA%CE%B1C%A6%A8%A8%AD%B3%A3%ACO%AF%D7%AA%D5 (shows no result and search box is empty) Expected Results: Resolves to http://www.facebook.com/search/?q=%E8%82%A5%E5%A9%86%E6%88%90%E8%BA%AB%E9%83%BD%E6%98%AF%E8%84%82%E8%82%AA (and query shows up in search box although no results) This happens because Firefox does not send query strings in UTF-8. I know this can be changed in about config (network.standard-url.encode-query-utf8) but this is not known by the average user. The solution could be to (1) permanently change it (2) pre-configured list of exceptions & changable with "View Page Info" (3) leave it there for developers to "fix" it server side (which would be pure ****) This fails on wikipedia when you don't use wikipedia's url masking (using index.php?title=) as the url masking was changed to utf in 2004 (BUG 261929). Another Example: Go to http://zh.wikipedia.org/w/index.php?title=水&action=edit It resolves to http://zh.wikipedia.org/w/index.php?title=%A4%F4&action=edit When network.standard-url.encode-query-utf8 is set to true, it resolves correctly to http://zh.wikipedia.org/w/index.php?title=%E6%B0%B4&action=edit You could say this "regressed" from 284474.
you'll need to copy and paste the url into the location bar for the Chinese links and not click on the url. The behavior is different. Oh and sorry the example for facebook doesn't use a very nice language (it says fat women have a body full of fat)
Isn't that the same behavior that IE has (per bug 284474)? Your solution 1 breaks other web sites, at least as I understand it, no? I'm not sure why your option 3 is "pure bullshit": if all the web pages on a site are UTF-8 encoded then the query string will also be UTF-8 encoded and everything will work. For example, your wikipedia links in this bug seem to work just fine (which suggests to me that the "go to" step in your steps to reproduce is missing some details).
Compared to IE(7), Opera, Safari, and Chrome, Firefox seems less consistent here. I can paste http://zh.wikipedia.org/w/index.php?title=%E6%B0%B4&action=edit into any of these browsers, and (of course) get to the right page. Opera and IE show the escaped URI. Safari, Chrome and Firefox show the unescaped http://zh.wikipedia.org/w/index.php?title=水&action=edit. When I repaste this, Safari and Chrome go again to the same page, but Firefox (and IE(7) and Opera, but in those cases, it's an initial paste, not a repaste) go to another page. (Opera goes to http://zh.wikipedia.org/w/index.php?title=%1B$B?e%1B(B&action=edit on my Japanese system, which is really weird, because the iso-2022 encoding that it's using here is the encoding of choice for Japanese email, but extremely minor for Japanase
[sorry, submitted too early, continuing from Comment 3] ...for Japanese Web pages. Firefox uses Shift_JIS, which in a Japanese context is quite a bit more reasonable, and shows this as http://zh.wikipedia.org/w/index.php?title=%90%85&action=edit. IE(7) also uses Shift_JIS, but to know this, one has to use something like Wireshark, because it shows http://zh.wikipedia.org/w/index.php?title=水&action=edit. IE(7), Chrome, Safari, and Opera are internally consistent when you copy an URI from the address field and repaste it. Firefox is inconsistent. For how to interpret IRIs that are pasted into the address bar, I think the right thing is to side with Safari and Chrome, because that's where the future lies (and it works across different OSes with different languages). But for displaying the query part, Opera's behavior of showing query parts escaped seems much more prudent for the time being.
> but Firefox (and IE(7) and Opera, but in those cases, it's an initial paste, > not a repaste) go to another page I can't reproduce this over here (current Mac trunk build). If I paste http://zh.wikipedia.org/w/index.php?title=%E6%B0%B4&action=edit into the url bar I see the unescaped string. If I then copy the unescaped string, then the escaped (as UTF-8) string is placed on the clipboard; pasting it of course goes to the right place. > you copy an URI from the address field and repaste it. Firefox is > inconsistent. For how to interpret IRIs that are pasted into the address bar, > I think the right thing is to side with Safari and Chrome Last I checked we use UTF-8 for IRIs pasted in the address bar. Certainly if I copy the unescaped IRI from comment 3 directly (by selecting the text) and paste it into my url bar I get the same result as I do with the UTF-8-escaped URI from the beginning of comment 3.
I just tried 3.6, and I see the same thing there. So I guess my point is that at least for me your steps to reproduce from comment 0 using wikipedia don't show a problem. The facebook steps obviously only give me only a login screen (no facebook account here). What are you doing differently from me? Can you describe the precise steps you take to reproduce the bug, keystroke by keystroke, starting with browser startup? There's always the off chance that it's a Mac vs Windows thing, of course, but I somehow doubt that...
I was indeed able to confirm that when pasting http://zh.wikipedia.org/w/index.php?title=%E6%B0%B4&action=edit, one then sees http://zh.wikipedia.org/w/index.php?title=水&action=edit, but re-copying this and pasting somewhere else again gets back to http://zh.wikipedia.org/w/index.php?title=%E6%B0%B4&action=edit. I can't explain what happened in comment 3, except that I may have pasted *visually* the same string as in the address bar, but not copied directly from the address bar. However, I can reconfirm that pasting http://zh.wikipedia.org/w/index.php?title=水&action=edit into Firefox (3.6.2, I get to http://zh.wikipedia.org/w/index.php?title=%90%85&action=edit. The explanation I can offer is not Mac vs. Windows, but European(?) vs. Asian (Chinese/Japanese) OS. I know there were some such dependencies for IE, at least some time ago, that's why I'm guessing that might be the case here.
Depends on: 333859
(In reply to comment #5) > I can't reproduce this over here (current Mac trunk build). This bug is not reproducable on Mac because Mac uses UTF-8 as a file system charset. The behavior of location bar depends on the platform charset. (In reply to comment #7) > The explanation I can offer is not Mac vs. Windows, but European(?) vs. Asian > (Chinese/Japanese) OS. I know there were some such dependencies for IE, at > least some time ago, that's why I'm guessing that might be the case here. Probably because the character "水" is not representable in European charsets. I could reproduce the problem with the URL below: http://ja.wikipedia.org/w/index.php?title=水&action=edit But could not reproduce with: http://ko.wikipedia.org/w/index.php?title=물&action=edit (I'm using Japanese Windows and Firefox)
I'm coming from Bug 580254, and I'm the server side developer. IMHO, it's very difficult for server side fix of this issue. The key point here is: if there are mixed Chinese characters + Japanese characters in a single URL, then, it's really hard to predict and decode the values. And I believe the best solution here is that always, the address bar takes the characters as UTF-8, and always encoding like that.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Masatoshi Kimura, why is this a duplicate? For the input strings in comment 0 CreateFixupURI shouldn't be involved.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
(In reply to comment #12) > Masatoshi Kimura, why is this a duplicate? For the input strings in comment 0 > CreateFixupURI shouldn't be involved. See also comment #1. CreateFixupURI affects the behavior of location bar.
1. Navigate to the URL. 2. Follow the link. Results: Firefox with "network.standard-url.encode-query-utf8" enabled: http://ja.wikipedia.org/w/index.php?title=%E6%B0%B4&action=edit Firefox with the CreateFixupURI patch and default settings, or Chrome: http://ja.wikipedia.org/w/index.php?title=%90%85&action=edit I propose to apply the CreateFixupURI patch again because: 1. It will not affect web pages at all. It only affects the behavior of location bar. Enabling "network.standard-url.encode-query-utf8" will "break" some web pages. 2. CreateFixupURI patch does no longer introduce "a new third behavior" because it's the same as Chrome. Meanwhile, enabling "network.standard-url.encode-query-utf8" does. No other browsers behaves as Firefox with "network.standard-url.encode-query-utf8" enabled. Do you have an objection?
URL: data:text/html;charset=Shift_JIS,<!DO...
> CreateFixupURI affects the behavior of location bar. Ah, indeed. I forgot that we call that even if newURI succeeds. > I propose to apply the CreateFixupURI patch again When it was applied, it broke sites. Are those sites no longer broken with it applied?
To be clear, some sites break if we don't send strings as UTF-8. Others break if we DO send them as UTF-8. I'd love to see a clear description of what other UAs do here. It might also be worth just getting this sorted out in whatwg once and for all.
(In reply to comment #15) > > I propose to apply the CreateFixupURI patch again > When it was applied, it broke sites. Are those sites no longer broken with it > applied? If those sites still broke, Chrome will also break them. Also, if CreateFixupURI patch break the site, it will also broken by "network.standard-url.encode-query-utf8" CreateFixupURI patch is safer because it will not change the behavior of links on web pages. Furthermore, http://www.kaply.com/work/chartest.php is already "broken" on Japanese locale because "–" and "å" are not representable in Shift_JIS. I think it's better to have a consistent behavior regardless the locale. (In reply to comment #16) > To be clear, some sites break if we don't send strings as UTF-8. Others break > if we DO send them as UTF-8. > > I'd love to see a clear description of what other UAs do here. It might also > be worth just getting this sorted out in whatwg once and for all. Should whatwg define the behavior of location bar? All browsers have a consistent behavior when folloing the link on web pages. The path component will be percent-encoded as UTF-8 while the query component will be percent-encoded as the document charset. RFC3987bis will also follow this existing convention. http://tools.ietf.org/html/draft-ietf-iri-3987bis-00 Obviously URLs on location bar do not have a document charset, so we are using platform charset now. Chrome uses UTF-8 in this situation.
> If those sites still broke, Chrome will also break them. Sure. Plenty of sites out there broken in chrome; as long as their user base is small enough they (Chrome _and_ the sites) don't care. > it will also broken by "network.standard-url.encode-query-utf8" Yes. You might have noticed that this pref hasn't been flipped... > I think it's better to have a consistent behavior regardless the locale. That would be nice, but if user behavior differs by locale such that different user populations have different "must have this work" sites that expect different behaviors from the browser ... then we end up in the situation we're in now. > Should whatwg define the behavior of location bar? Normatively, perhaps not. Informatively, it would be more useful than a lot of other things they're doing in terms of actually achieving interoperability. > Obviously URLs on location bar do not have a document charset, so we are using > platform charset now. Chrome uses UTF-8 in this situation. Right. Maybe we should be smarter about it? e.g. if we ever visited the page in the past use the charset it had then? This would make any error transient, at least... I'd love to move to all-UTF8 (so effectively IRI) for this stuff. My worry is that this _will_ break things, and it's not clear to me that it would break more than it would fix. Another interesting possibility, if that's what the server landscape looks like, is to use platform charset if that's ISO-8859-1 (or some bigger whitelist) and UTF-8 otherwise. It's extra complexity, but maybe that's needed here...
(In reply to comment #18) > Right. Maybe we should be smarter about it? e.g. if we ever visited the page > in the past use the charset it had then? This would make any error transient, > at least... That's a great idea if possible. Is the charset information available from the history? > Another interesting possibility, if that's what the server landscape looks > like, is to use platform charset if that's ISO-8859-1 (or some bigger > whitelist) and UTF-8 otherwise. It's extra complexity, but maybe that's > needed here... It looks a good compromise if the first idea is too complex.
> Is the charset information available from the history? Not at the moment, but we could change that, I think... Shawn?
(In reply to comment #20) > Not at the moment, but we could change that, I think... Shawn? We could, but we'd want to make a new async API instead of using annotations. Or make an async annotation API. Totally doable though. If we need an API spec'd out, let me know (but I don't think the places team has time to implement it before Firefox 4).
Since there is not an official standard, whether one solution is better than the other, IMHO, can be evaluated by whether the behavior is predictable from the server side where the URLs are parsed (consumed). As a server side developer, I vote for any solution which helps servlet to understand which encoding should be used to decode the parameters from a URL. Under this criteria, Chome and Safari do a better job: they always send ISO-8859-1 + UTF-8, so, for me, as a server side developer, they are better. Why current FireFox behavior is not predictable? Server side cannot know what's the client OS settings, so cannot tell which encoding FireFox is actually sending. Yes, Chome and Safari also break some (or lot of) web sites. For example, for those web site who just think they will work on Chinese, this is because 1) those applications only expecting visits from IE, 2) they only testing English and Chinese. In a short word, to me, they are not designed for globalization from day one. I guess from FireFox perspective, it's OK to break there, because 1) they will catch up once they are starting thinking globalization 2) they should have been known the risks to build applications on a undefined behavior of browsers.
> whether the behavior is predictable from the server side where the URLs are > parsed If we were coming up with a new standard and had a blank slate, absolutely. Unfortunately, we are in the situation of having to deal with existing deployed content that makes inconsistent assumptions about this. > Server side cannot know what's the client OS settings, so cannot tell which > encoding FireFox is actually sending. Yes, but most servers just assume an encoding no matter what, and they assume _inconsistent_ ones. To me it sounds like you're saying "ah, screw over those tens of millions of European users, if the servers they visit make different assumptions from the servers I visit". I understand that a predictable behavior would be better if possible; hence some of the proposed solutions in comment 18. > I guess from FireFox perspective, it's OK to break there No, it's not. > they should have been known the risks to build applications on a undefined > behavior of browsers. You must be new to the web.... half of it is built in just this way; if browsers were willing to break everyone who does it, nothing would work.
> If we were coming up with a new standard and had a blank slate, absolutely. > Unfortunately, we are in the situation of having to deal with existing deployed > content that makes inconsistent assumptions about this. There is no standard there, so, no standard can be broken to introduce one (even it's fine to make the existing implementation formal also means to introduce a new standard). > Yes, but most servers just assume an encoding no matter what, and they assume > _inconsistent_ ones. To me it sounds like you're saying "ah, screw over those > tens of millions of European users, if the servers they visit make different > assumptions from the servers I visit". > > I understand that a predictable behavior would be better if possible; hence > some of the proposed solutions in comment 18. Regional of users impacted not the topic here (I'm living in Asia, here more people are living in non-ASCII world). What I'm trying to say here is: 1) most of those applications developed before FireFox becomes popular 2) we need to take care what we have, but cannot put the cost of future. One question we should ask: how long FireFox coming to the center of the stage? How many those web site is actually tested with FireFox? I know that there are also tons of web sites are using ActiveX, and how about those? I agree to take those web sites as much as possible, but some day, for some reason, things may change. btw: I don't know whether I still can be tagged as "new to the web", but actually like to be "new to the web", since world of web is changing everyday... Thanks. :-)
> no standard can be broken No de-jure standard. de-facto standards (like "All browsers in Europe and all servers in Europe do query strings in ISO-8859-1") can be. > most of those applications developed before FireFox becomes popular Perhaps. If the default php behavior is broken, as indicated in other bugs on this topic, that may well not be the case... > we need to take care what we have, but cannot put the cost of future. I'm not sure what you mean there. > How many those web site is actually tested with FireFox? A fair number, but even the ones that are tested are usually tested _after_ release. Often significantly after. In practice, there would be a period of months to years where they don't work if we broke something that works right now. > I know that there are also tons of web sites are using ActiveX Not on the internet (except in S. Korea, of course). Most ActiveX content is on intranets, where different rules apply about whether people are allowed to switch browsers. > but some day, for some reason, things may change. Sure, and I think we all agree that moving on to UTF-8 is the right long-term goal; the question is how to do that without causing problems for tens of millions of people in the process...
In case anyone still misunderstands this (as #3,4,5,6,7) (#7, starting from "however" seemed to get it right) The bug is when you paste the url: "http://zh.wikipedia.org/w/index.php?title=水&action=edit" directly into the awesome bar. (Different side effects happen when you copy and paste the resolved address, but that's not THIS bug.) It resolves the unescaped character with the current system encoding instead of UTF-8. [[@Masatoshi Kimura#14 "Firefox with "network.standard-url.encode-query-utf8" enabled: http://ja.wikipedia.org/w/index.php?title=%E6%B0%B4&action=edit Firefox with the CreateFixupURI patch and default settings, or Chrome: http://ja.wikipedia.org/w/index.php?title=%90%85&action=edit"]] Google Chrome (at least my version, 5.0 on windows 7) uses UTF-8 for query string. behavior is exactly the same as flipping network.standard-url.encode-query-utf8. I don't think (the current) CreateFixupURI would fix this. %90%85 resolves to the article for "…" in ja:wiki. Not water. [[@Boris#2: "I'm not sure why your option 3 is "pure ****": if all the web pages on a site are UTF-8 encoded then the query string will also be UTF-8 encoded and everything will work."]] Firefox doesn't do any detection to what I know. (Unless you're doing it wrong) ------------------------------------------------------------------------- What I'm suggesting here is to flip the switch of "network.standard-url.encode-query-utf8" to TRUE for existing profiles and use as default. [[@Boris#25: "Sure, and I think we all agree that moving on to UTF-8 is the right long-term goal; the question is how to do that without causing problems for tens of millions of people in the process..."]] ms box model broke half of the web. ms box model still persists for some input elements even in strict mode for some older versions of gecko/webkit. using UTF+8 for urls broke IIS 6 servers. any new web application/server script is likely to be built for unicode (wikiMedia, fb). and getting these new web apps to support automatic detection of other (older) encodings is just like back-porting a page for ie5. It wastes time. (definition of ****) just use the "break-and-evangelise" moz has done so many times. and break it with Firefox 4 like it breaks text/html served css in quirks mode. Using system-depended encoding for querystring but sending other parts of url (and even POST) in UTF-8 is quirky to me. and flipping the switch doesn't break wikipedia/facebook, it fixes it.
*whoops pressed save too quick It's paste "http://zh.wikipedia.org/w/index.php?title=水&action=edit" into awesome bar directly, not middle click or open in new tab. bugzilla is UTF-8 and firefox resolves the address as utf-8 is you middle click on it. And i still don't quite understand why resolving querystring (System encoding) doesn't match the resolving of other parts of the URL (UTF+8). Break it guys. Its like webkit using the ms-box-model for fixed layout tables even in strict mode. It's dumb. getting php <= 5.3 to accept UTF-8 as query string and transcode into watever encoding the server is using is just one line: iconv_set_encoding('input_encoding', "UTF-8"); and many CMSs are using UTF-8 as default with this: iconv_set_encoding('input_encoding', "UTF-8"); iconv_set_encoding('output_encoding', "UTF-8"); iconv_set_encoding('internal_encoding', "UTF-8"); and big webapp providers are already using servers with default locale as UTF-8. I see no point in this 'quirky' behavior. filed bug in for IE9. https://connect.microsoft.com/IE/feedback/details/586922/querystrings-in-url-are-sent-in-system-default-encoding-even-when-send-utf-8-urls-is-checked [[This bug is ONLY related to pasting the not-yet-encodeURIComponent-ed address directly into the awesome bar, blank page or not. Any link on the page will resolve automatically according to the page encoding.]]
Could we do this for a beta or two and watch feedback?
I don't think it's possible. Changing this will break many other websites and it is incompatible with other browsers.
@Masatoshi Kimura: This will bring Firefox in line with Google Chrome.
(In reply to comment #31) > This will bring Firefox in line with Google Chrome. Google Chrome do NOT encode URL with UTF-8 on non-UTF-8 page. We should only change the location bar's behavior if we change.
network.standard-url.encode-query-utf8 ONLY affects url resolving when pasting urls directly into the browser. Eg. Trying pasting into the location bar: http://zh.wikipedia.org/w/index.php?title=水&action=edit Correctly resolved: http://zh.wikipedia.org/w/index.php?title=%E6%B0%B4&action=edit Incorrectly resolved: http://zh.wikipedia.org/w/index.php?title=%A4%F4&action=edit Google Chrome 7.0.517.41 on Windows 7 (en-us) resolves correctly. @Masatoshi Kimura #32 "Google Chrome do NOT encode URL with UTF-8 on non-UTF-8 page.": network.standard-url.encode-query-utf8 DOES NOT AFFECT LINKS ON PAGES ON NON-UTF-8 PAGES! This switch affects pages ONLY when you PASTE unescaped url into the location bar. ONLY! This switch does NOT mean to resolve all query strings to UTF-8 independent of page encoding. What you're seeing is totally nothing to do with this bug.
Please also see bug 443588.
this bug is not replicable with the URL provided. AGAIN: this bug is ONLY related to when the user enters/pastes the URL directly, NOT related to clicking on links.
(In reply to comment #35) > this bug is not replicable with the URL provided. Because your system code page can not encode Japanese characters. If the system code page can not encode the character, Firefox fallbacks to UTF-8. It's the reason you don't see the difference. Changing network.standard-url.encode-query-utf8 to true is not acceptable for Japanese and Chinese users. It will change the behavior on their locales.
Sorry, please disregard comment #36. Although the previous testcase did not depend on system codepage, but it was confusing ("Editing …" was the expected result and "Editing 水" was unexpected). I've added a new testcase. Steps to reproduce: 1. Turn network.standard-url.encode-query-utf8 to true. 2. Open the URL. 3. Click the link. Actual result: It will search for "豌ｴ" (mojibake). Expected result: It should search for "水". This is reproducable regardless of the system locale. Chrome, Safari, Opera, and Firefox without network.standard-url.encode-query-utf8 work as expected.
URL: data:text/html;charset=Shift_JIS,<!DO...
OK, so how do we solve the problem of directly pasting a url into the location bar? Currently firefox and ie and opera resolve them according to system codepage while google chrome takes UTF-8. "Changing network.standard-url.encode-query-utf8 to true is not acceptable for Japanese and Chinese users. It will change the behavior on their locales." see bug 443588. the default of "network.standard-url.encode-query-utf8" has long been changed to true for zh-TW. Just test this with wikipedia or facebook. generally most websites are now utf-8 including google if you changed your link from http://www.google.co.jp/search?q=水&ie=Shift_JIS to http://www.google.co.jp/search?q=水&ie=UTF-8 Why should we have different behavior for query string and directory? I don't see the point of this. especially if http://ja.wikipedia.org/wiki/水 goes to http://ja.wikipedia.org/wiki/%E6%B0%B4 while http://ja.wikipedia.org/w/index.php?title=水 goes to http://ja.wikipedia.org/w/index.php?title=%A4%F4 NOT reasonable. So make query string behave like url path. One more thing, if "network.standard-url.encode-utf8=true" doesn't affect links on non-utf8 pages, why does "network.standard-url.encode-querystring-utf8" affect it?
again, you'll have to PASTE the links into the location bar to see the effects; bugzilla is UTF-8 so firefox encodes the query string thru page encoding.
OK Sorry, ignore the last paragraph of comment #38 and all of comment #39. Paste this into google chrome: data:text/html;charset=Shift-JIS,<!DOCTYPE%20html><meta%20charset="Shift-JIS"><a%20href="http://ja.wikipedia.org/wiki/%90%85">%90%85</a>%20<a%20href="http://ja.wikipedia.org/w/index.php?title=%90%85">%90%85</a> first one takes you to 水, second one takes you to …. Try this in firefox. first one takes you to 水, second one takes you to …. Ok now paste http://ja.wikipedia.org/w/index.php?title=水 into the location bar of google chrome. Result: 水 Firefox? Result: ¤ô Ok, so maybe i misunderstood network.standard-url.encode-query-utf8. I now see how it 'breaks' some sites. Personally, as a web dev, I'd opt to switch the flip. Flipping network.standard-url.encode-utf8 broke a lot of sites. The fact that the behavior for query string differs from url path makes it a pain in the neck for a program to detect the encoding. and remember that it breaks wikipedia and facebook because they assume both path and query string is utf-8 (since they serve utf-8 as well) break and evangelize.
(In reply to comment #38) > OK, so how do we solve the problem of directly pasting a url into the location > bar? CreateFixupURI patch (bug 393246) will only change the location bar's behavior. But the patch was rejected because it broke some old Western sites.
(In reply to comment #41) > CreateFixupURI patch (bug 393246) will only change the location bar's behavior. > But the patch was rejected because it broke some old Western sites. Of course network.standard-url.encode-utf8=true will also break those sites. So I don't think we can fix this bug before bug 393246 is fixed.
(In reply to henry.fai.hang.chan from comment #38) > see bug 443588. > the default of "network.standard-url.encode-query-utf8" has long been > changed to true for zh-TW. Then it caused bug 647403. It is the very reason I'm opposed to the change.
Eventually bug 393246 has been fixed. Firefox should behave in line with Chrome regarding to URLs in the location bar.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 12 years ago
Depends on: 393246
Resolution: --- → FIXED
Assignee: nobody → hsivonen
Target Milestone: --- → mozilla28
Keywords: verifyme
I've reproduced the bug using the steps from comment 37 and the following environment: FF 3.7a5pre Build Id:20100501040355 OS : Win 7 I verified the bug using the following environment: FF 28 User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 Build Id:20140218122424 Os: Win 7
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.