55366 unknown 2000-10-05 12:17:47 -0700 Don't reveal UI language to site/page -- Change navigator.language to use Accept-Language instead of the UI language 2019-03-13 06:42:05 -0700 1 1 3 Components Core DOM: Core & HTML Trunk All All defect RESOLVED FIXED http://gemal.dk/browserspy/language.html [defective-privacy] dev-doc-complete, privacy P4 normal mozilla5 572656 610267 418485 646428 1386461 1 ben.bucksch ben.bucksch aha andrewm715+bugzilla antoine.mechelynck asa barrowma bartml ben.bucksch bobj bugzilla bzbarsky cbegle cesarb chpe daniel dao+bmo dbaron deletesoftware+moz deprecationmail djcater+bugzilla dveditz ehsan.akhgari erik gagan gavin.sharp gionnico gk gphemsley haqer hsivonen jmd john jorgev jstenback+bmo jud kairo karl l10n loadrunner maxxmozilla messi mike.shaver momoi mozbugz mozilla msanz obsolete.fax pascalc pb-dsp_bugzilla pbartecki pgunn01 piskozub reed roberts ryanvm shawn.sumin smorrison the.sheppy toniher verah xtc4uall --- --- --- --- --- --- --- --- --- --- --- - --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 2011-03-30 11:37:30 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 2011-03-30 11:37:30 5 462775 ben.bucksch 2000-10-05 12:17:47 -0700 Reproduce: 1. Visit <http://gemal.dk/browserspy/language.html>. Actual result: Your UI language and locale (e.g. en-US) is displayed. Expected result: Neither UI nor OS language or locale are revealed to page or site. Additional Comments: Compare HTTP 1.1. spec: <quote src="http://www.ietf.org/rfc/rfc2616.txt"> 15.1.4 Privacy Issues Connected to Accept Headers Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header in particular can reveal information the user would consider to be of a private nature, because the understanding of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option to configure the contents of an Accept-Language header to be sent in every request are strongly encouraged to let the configuration process include a message which makes the user aware of the loss of privacy involved. An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default, and to ask the user whether or not to start sending Accept-Language headers to a server if it detects, by looking for any Vary response-header fields generated by the server, that such sending could improve the quality of service. Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability SHOULD warn users about the loss of privacy which can be involved. </quote> While we don't send this info as HTTP header, we offer it as JS property. See the source of the testcase mentioned above for details. 466753 mozilla 2000-10-09 01:39:35 -0700 Isn't the language info also in the useragent string? According to the browser sniffer at http://www.ufaq.org/ it is. User Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m18) Gecko/20001006 Application Name: Netscape Application Version: 5.0 (X11; en-US) While this could be considered a privacy thing, it could be really neat if sites tailored what language their content was according to your locale and language. 466756 mozilla 2000-10-09 01:42:30 -0700 Hmm, on section thought maybe this isn't so good. I recommend disabling it or at least pref-disabling it. 466833 ben.bucksch 2000-10-09 04:53:34 -0700 David, you are right and everything is as you suggested it. See the pref UI pane under Navigator - it configures the HTTP header to send. This bug is about the JS property which is - much less useful (do you want to send all available language versions and then select onteh client side?) - not opt-in - corrently not (independantly) changeable by the user, but identical to the UI language . 468779 timeless 2000-10-10 07:13:41 -0700 The useragent should not include this information. But the point of accept is to say that the user WANTS the content in that language. Some RFCs need comments like ~this is stupid and counterproductive~. Verah I think you work on that privacy document, add a paragraph w/ link to that rfc: According to <a>RFC</a> we do hereby warn you that asking for content in a language you prefer might divulge information about you (including <span style="-moz-type-timeless:shocking">the language you prefer to read</span>, which may imply <span style="-moz-type-timeless:shocking">your ethnicity</span>). I presume mozilla does send prefered language headers, if not we need a bug for that (mozilla1.0) 468858 ben.bucksch 2000-10-10 08:34:15 -0700 timeless, I don't understand your last comment. Also, it has nothing to do with privacy *links* (maybe the *document*). Removing dependancy. Please note the difference between the HTTP header "Accept-Language" and the JS property. The implementation of the former is OK in Mozilla (I think). This bug is about the latter. David Krause, thanks for noting the UA string (anyhow, I missed your comment). Will investigate. 481515 security-bugs 2000-10-18 12:13:10 -0700 Future. 490062 gerv 2000-10-25 04:27:15 -0700 As there's nothing a user can do about this JS privacy leak, is it worth relnoting? The blurb: It seems unclear to me whether this bug requires either of a "developer" or "user" release note for Netscape 6 RTM. If anyone feels it does, can they please draft one and then nominate with the relnote-user or relnote-devel strings in the Status Whiteboard. Thanks :-) Gerv 490068 ben.bucksch 2000-10-25 04:33:13 -0700 > As there's nothing a user can do about this JS privacy leak, is it worth > relnoting? Sure, at least he has to know. He can do something: Use another UA or use english chrome. 491051 security-bugs 2000-10-25 14:56:15 -0700 Hasn't Netscape always revealed the UI language somehow? If this behavior is present in 4.x, then I don't see why we need a relnote. 491157 ben.bucksch 2000-10-25 15:47:46 -0700 > Hasn't Netscape always revealed the UI language somehow? Yes, I think so. I am not sure we need a relnote. 493316 ben.bucksch 2000-10-26 23:43:21 -0700 We *already* have something better than a relnote: Tasks|Privacy|Understanding <chrome://communicator/locale/wallet/privacy.html>. removing relnoteRTM based on that. 511693 junruh 2000-11-14 10:19:05 -0800 Mass changing QA to ckritzer. 736122 danielmc 2001-05-22 06:49:04 -0700 We are past the UI freeze for Commmercial Beta. We need a UI freeze to ba able to ship Localised products simultaneously with the US. Would it be possible to check any changes to chrome://communicator/locale/wallet/privacy.html after we have branched in the commercial tree on 6/29? 736125 danielmc 2001-05-22 06:57:54 -0700 By the way here is a handy JS for revealing UA info... <PRE> <SCRIPT> with (document) { writeln("navigator.userAgent is ", navigator.userAgent); writeln("navigator.appCodeName is ", navigator.appCodeName); writeln("navigator.appVersion is ", navigator.appVersion); writeln("navigator.appName is ", navigator.appName); } </SCRIPT> </PRE> 844216 security-bugs 2001-07-26 16:36:30 -0700 Target is now 0.9.5, Priority P1. 844315 ben.bucksch 2001-07-26 17:32:21 -0700 Removing this info from the UA string is trivial. I did this for Beonex Communicator, I can attach a patch. 845007 security-bugs 2001-07-27 10:35:30 -0700 Ben, By all means, attach your patch. I don't think we will make it the default, but it would be nice to have as part of "high-privacy mode," which is something I'm working on. 845765 ben.bucksch 2001-07-27 19:23:25 -0700 Mitch, why not make it the default? The HTTP spec explicitly recommends against doing what we do atm. Sites won't break either, if we just always send "en-US". (But possibly with an Accept-Language header, which is customized by the user.) 845773 43864 ben.bucksch 2001-07-27 19:36:28 -0700 Created attachment 43864 Proposed Fix for UA-string. Also contains Win fix for bug 57555. 845782 ben.bucksch 2001-07-27 20:03:31 -0700 > (But possibly with an Accept-Language header, which is customized by the user.) s/with/, we send/ 847545 security-bugs 2001-07-30 13:39:49 -0700 It's not my decision to make. I will ask around here and find out if changing the default UA is OK. There may be some resistance to changing it at all, especially if we've always provided the language information in the UA. 847912 timeless 2001-07-30 17:32:59 -0700 this was discussed in a newsgruop that i read recently (well the discussion was 1-4 years old but...) cc. 848156 jmd 2001-07-30 20:44:58 -0700 Ben, does your patch remove the region/language from navigator.appVersion as well? 848255 ben.bucksch 2001-07-30 23:59:35 -0700 Yes, it seems so. The test page now shows "en" (the hardcoded dummy value) instead of "en-US". Looks like the Javascript function pulls its value out of the UA-string, which is nice. So, looks like I fixed this bug. I'll install a German langpack when I get a chance to be sure. mstoltz, would you mind, if I took the bug? Who has to be asked about checking this in, apart from dbaron? (There's no pref to turn this on or off, since I see no value in the current behaviour - see comment in patch and my earlier comments here for reasons.) dbaron, what do you think? 848268 ben.bucksch 2001-07-31 00:18:53 -0700 Posted proposal to .netlib: <news://news.mozilla.org/3B665A87.8050807@beonex.com>. 848297 momoi 2001-07-31 01:09:11 -0700 > It's not my decision to make. I will ask around here and find > out if changing the default UA is OK. There may be some > resistance to changing it at all, especially if we've always > provided the language information in the UA. Netscape commercial builds cannot remove the lang info from UA string. They serve as important tracking tools. If Mozilla wants to make that an option, that is fine but that option should not be the default. If there is a proposed UI for it, commercial builds might consider removing the UI. 848305 ben.bucksch 2001-07-31 01:30:42 -0700 > If Mozilla wants to make that an option, that is fine > but that option should not be the default. Why? If it's a pref, Netscape can alter it trivially. 848313 momoi 2001-07-31 01:44:56 -0700 >> If Mozilla wants to make that an option, that is fine >> but that option should not be the default. > Why? If it's a pref, Netscape can alter it trivially. That is true. As long as it is Netscape's default not to turn off lang info, that would be fine. By the way I would like to raise this issue about the privacy clause in HHTP 1.1. It is wrong-headed to single out lang info as the only thing compromising security. What about the fact that you're using Mozilla, Gecko, or Netscape, Win NT5, etc. ? Why, someone could descriminate against Netscape users or IE users or whatever. That is also a privacy issue if lang info is a privacy issue. The fact that somethng is mentioned in an RFC document does not mean we need to be implementing everything that is in it. In these day and age, the fact that someone might be using en-US build means virtually nothing other than the fact that someone maight be able to read English. We have users all over the world using an en-US build. The fact that someone is using using an ja-JP build does not mean that that person is Japanese. It simple means that someone possibly reads Japanese but may be a Canadian, etc. The whole argument about the lang info being a compromising factor is moot in my opinion. Whoever wrote the HTTP 1.1 section onlang info and security should examine issues more broadly and fairly. Our proud Mozilla localizers around the world would probably like to see their L10 work reflected accurately in the UA string. 848322 ben.bucksch 2001-07-31 02:02:22 -0700 > wrong to single out lang info as the only thing compromising security. Right. There are other bugs about other issues, e.g. bug 57555. > en-US build means virtually nothing Right, but if I speak Hebrew, it does mean something. You can argue about the severity of this bug. But I do think that it should be fixed. I care less about the default in Mozilla, but I would prefer that Mozilla followed the advise of the spec. I will attach a new patch which makes it dependant on a pref (browser.reveal-ui-lang or similar) when I have time. 848514 timeless 2001-07-31 09:38:56 -0700 ben: you're german no? I know a bunch of people who contribute to mozilla.org who can read hebrew and I wonder if _any_ of them have this concern (I know it's really odd ..) 848793 tao 2001-07-31 11:32:52 -0700 Folks: Some websites sniff U-A string to redirect users to appropriate pages for downloading localized version of their software/patch. When locale info does not present, "en-US" are often used as the default. Following spec is a good thing when it does not break existing websites. I agree that making it a preference and default to 'on' seems to be a good compromise. 848939 jmd 2001-07-31 12:57:07 -0700 > Some websites sniff U-A string to redirect users to appropriate pages for > downloading localized version of their software/patch. IE 5.0, 5.01, 5.5, and presumably earlier versions don't put language in UA. Opera doesn't put language in UA. Konqueror doesn't put language in UA. This is a wholly unappropriate and nonportable place for that information. That's the whole purpose of the Accept-Language header, to specify what language you want information in. If you want to ignore the RFC and default Accept-Language to on, that's fine enough by me (and is a seperate bug anyway). But there's no purpose to reveal the *UI* language, if not for privacy, for correctness. Accept-Language is the language(s) the user wants to receive information in. 848962 tao 2001-07-31 13:11:48 -0700 I don't think I've ever said that it is proper to use U-A string for content negotiation; as you pointed out, accept-lang in the HTTP header serves such purpose. All I said is there are indeed websites misuse the U-A string... Glad hear standard advocate, though :-) 849090 momoi 2001-07-31 14:02:28 -0700 > But there's no purpose to reveal the *UI* language, if not > for privacy, for correctness. Accept-Language is the > language(s) the user wants to receive information in. I think you should read the definition of User-agent: "14.43 User-Agent The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens (section 3.8) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application. User-Agent = "User-Agent" ":" 1*( product | comment ) Example: User-Agent: CERN-LineMode/2.15 libwww/2" Further Product tokens are deifned as: " Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields using product tokens also allow sub-products which form a significant part of the application to be listed, separated by white space. By convention, the products are listed in order of their significance for identifying the application. .... etc." UI language differs if localization files are different. It is clearly a significant part of the application. And though this is not common, localization itself might reveal a bug that was not caught before the product was shipped. This latter type of case does actually. For tracking purposes, it is in my opinion siginificant info. I don't believe that we should use considerations raised for Accept-Language for user-agent issues. I just want to point out that there are arguments for both sides of this issue and also that the HTTP 1.1 says nothing about not revealing the UI language in the User-agent header. If MS or Opera wants not to include that info, that is fine but let that not bind what we should do here. 849138 jmd 2001-07-31 14:27:51 -0700 Keep in mind, that where the RFC says "automated recognition of user agents for the sake of tailoring responses", I think this would more refer to protocol tailoring, not content. For example, Apache's default config contains some magic to disable Keep-Alive for some broken versions of IE that claim to support it. HTML includes its own means of "avoid[ing] particular user agent limitations", such as CSS, and other ways of making content still accessible to older browsers. The only browser revealing language in U-A I know of is Netscape 4.*, which, last I heard, had 8% market share. Any page basing content off this field isn't a whole hell of a lot effective right now. If future versions of Mozilla and Netscape 6 remove it from U-A, more web designers won't be tricked into mistaking U-A for A-L (see also: Microsoft J++). OK, I'll shutup now, sorry for all the spam, folks. 849253 dveditz 2001-07-31 15:43:24 -0700 The user agent language is used for distribution tracking, right? Personally if I were creating a language pack I'd be gratified to have a clue how far it had spread, especially for a minority/endangered language (Navaho? Hawaiian? Gaelic?). If I were using such a language I'd probably want to signify my presence (ethnic pride). This kind of thing should obviously be a pref. (and now we can commence arguing over the default setting in Mozilla.) If the UA were easier to change (i.e. via the pref UI rather than hacking prefs.js) this wouldn't be so much of an issue. As the person mostly responsible for foisting "navigator.language" on people in 4.x I think we could safely nuke it. Eh, I guess we should return a string so we don't break pages accidentally on an undefined property, maybe "" or "unknown". 849272 tao 2001-07-31 15:53:42 -0700 Hi, Kat: We should probably inform webmasters of whatever change we make in the final so they can adapt accordingly. 849378 security-bugs 2001-07-31 17:06:05 -0700 I agree that we should have a pref. I don't know what the default setting should be, but I would lean towards leaving the language in there by default. We should have a pref checkbox for "paranoid mode" that will turn off the language part of the UA as well as other small privacy violations which are the norm. 849385 piskozub 2001-07-31 17:10:22 -0700 I believe that as mst potential Mozilla users does not live in zones of war or ethnic cleansing, the default setting should be the present behavior. 849601 ben.bucksch 2001-07-31 20:48:32 -0700 > as mst potential Mozilla users does not live in zones of war or ethnic > cleansing, the default setting should be the present behavior. The problem is that users might not know that we spread this info. And it's not worth a UI pref IMO. Default in Mozilla: So far, I count 1+4 (non-Netscape+Netscape) votes for on, 4+0 for off/dummy. 849704 dveditz 2001-07-31 22:39:29 -0700 Any votes gathered here are going to be meaningless because mostly only people who agree will find this bug. People who are happy with the way things are have no clue others want to change things--though I will grant that most people probably don't care one way or another. The navigator.language issue should be dealt with separately. IMHO axe that, leave the UA the way it is, and make it a hell of a lot easier for people to spoof the UA (e.g. pref UI with radio-buttons for common options and then a text box for custom text). Paranoid nuts who are worried about language in the UA also don't like giving out OS info and nearly everything else in the UA -- we shouldn't address UA privacy issues item by item. So is this bug about navigator.language, or is it about the UA? If the latter it should be invalid, in favor of some UA uber-bug 849824 daniel 2001-08-01 00:34:01 -0700 Just to show that I am the kind of person who cares about languages : I use a browser with an english UI. I configured it so it accepts the following languages in this order : French, English, Swedish, Spanish, Yiddish, Xhosa. And the person who Cc:ed me (timeless ?)on this bug also knows that privacy is on top of list of my concerns. I think this bug is a total non issue and a waste of time and neurons. We have language strings crossing the web in all directions since 1996 and nobody never ever complained about it. My 0.02? only... 849876 ben.bucksch 2001-08-01 01:21:14 -0700 > People who are happy with the way things are have no clue others want to > change things Right. OK, you talked me into making to default on for Mozilla. > The navigator.language issue should be dealt with separately. IMHO axe that, I care more about the UA-string, since we are really spreading this all over the world and playing it in many server-logs. Implementation is coupled. > and make it a hell of a lot easier for people to spoof the UA (e.g. pref UI > with radio-buttons for common options and then a text box for custom text) There is a bug about it, but it has its own problems, like (by the user) unintended side-effects. I am not a fan of having UI for setting the UA-string to arbitary values. > So is this bug about navigator.language, or is it about the UA? If the latter > it should be invalid, in favor of some UA uber-bug It's about both ("don't reveal" includes all ways). But it is INVALID in no case, because it's a legal request. It is also disabled in Beonex Communicator (by default), so I would appreciate, if I wouldn't have to carry around source patches. If I attach a patch to make it depending on a pref, default on, everybody is happy, no? 849908 jmd 2001-08-01 02:19:58 -0700 I was originally arguing to remove the language from U-A, but enough NSCPies want to leave it for various reasons, so I say just leave it. I didn't notice 4.7 had been doing it all this time, so it's nothing urgent. If it becomes an issue, we'll address it post 1.0. But for god sakes, don't make it a pref. And certainly no UI. If anything, a generic U-A pref (also with no UI, or a plain textbox under Debug... none of this multi pulldown nonsense) could be used to remove it, or, I have a bug open on disabling U-A altogether. But seperate prefs to tweak each part of the U-A string would be nuts. 850192 dveditz 2001-08-01 09:59:35 -0700 Ben, implementation could be trivially uncoupled if we wanted to deal with navigator.language separately. >> is it about the UA? If the latter it should be invalid, in favor >> of some UA uber-bug > > It's about both ("don't reveal" includes all ways). But it is INVALID in no > case, because it's a legal request. It's a valid concern, but wrong to consider in isolation from the other user-agent privacy concerns. Do you really want a bunch of "Hide UA Language", "Hide UA platform", "Hide UA OS", "Hide UA OS version", etc. prefs? The UI would be ugly which means they'd be hidden prefs, and that means most people who might benefit would have no clue they were there. 850277 mike.shaver 2001-08-01 10:38:58 -0700 If IE 5.0 and 5.5 don't send the language in the UA string, how many sites can we really be breaking? I think the compatibility stance so far, in DOM and other key areas, has been that if IE5 and NS4 do different things, we should ape IE5 because it has so many more users. (I'm sure that localization folks would love to know how many people are using their work, and I have no problem with that desire, but I don't want to turn the UA string into about:credits.) The argument that we've been doing this since 1996 doesn't sway me: browsers had privacy-hostile cookie and image handling for years to, but I'm pretty sure nobody's going to stand up and say that fixing it doesn't matter. I'd support pulling UI language out of the UA because - people should be using Accept-Language to tailor content - I can't believe that we're functionally breaking that many sites if IE doesn't do this, and the browser-number-tracking stuff really doesn't sway me, because, again, IE is the majority of the browser population, and you can't do this kind of tracking on it - there's too much crap in the UA anyway 850354 tao 2001-08-01 11:21:34 -0700 >If IE 5.0 and 5.5 don't send the language in the UA string, how many sites can >we really be breaking? Some websites have logic like this: if (Netscape) { // assuming locale info presents do some locale specific things... } else if (MSIE) { do nothing... } else { do nothing.. } The problem is more like Netscape used to include locale info in the U-A and some websites use it to do something for international users. Unless webmasters are advised of any upcoming change, their websites are doomed to break. I won't be surprised to see they start advising people that they websites work better with other browsers. 850950 security-bugs 2001-08-01 14:33:33 -0700 I agree with dveditz. People who care whether or not their UI language is revealed in the UA string probably also don't want their browser and OS versions revealed. We already have a (hidden) pref for overriding the UA string; why don't we just encourage people to use that? 850978 piskozub 2001-08-01 14:45:46 -0700 Mitchell: One of the reasons is bug 83376. It seems Sun Java uses the UA to check if the browser is Netscape/Mozilla. It is either free choice of UA or working Java :-( 851036 timeless 2001-08-01 15:11:27 -0700 please IGNORE the sun jvm problem, that's a bug which someone working on oji or the sun jre will fix, it shouldn't ask us about our spoofable useragent. All things considered a simple pref could probably be exposed: [x] Include system and locale information in useragent. checked by default. unchecking it would strip out all information except very basic stuff. 851061 piskozub 2001-08-01 15:30:05 -0700 Timeless: I'm actually for ignoring the Java bug. The thing that bothers me is the reply from Sun edburns@acm.org posted on 7/17 as a comment to bug 83376: > Java Plug-in depends on user-agent string for version information, no fix > will be made. > > zhengyu.gu@sun.com I believe this needs applyng some pressure on Sun. 908991 tpowellmoz 2001-09-07 15:17:53 -0700 Although IE5,IE5.5 do not include the language in the user agent string, they do expose it in JavaScript through navigator.userLanguage and navigator.systemLanguage. I believe navigator.language should continue to report useful and accurate information in Mozilla. Perhaps the language returned can be talored to the accept language stuff under edit->prefs->navigator->language. Perhaps report the prefered language. It seems that this is the only way the DOM can configure to the language, which could be useful if not serving special pages for each language. I don't see any reason to remove this from UA by default, especially since we allow changing the UA completely. I've always thought that this was one of the nicer features of N4. 909198 bobj 2001-09-07 17:15:13 -0700 > Perhaps the language returned can be > talored to the accept language stuff under edit->prefs->navigator->language. > Perhaps report the prefered language. These are different. The string in the u-a indicates the browser localization (i.e. the browser UI and some default settings). The pref indicates the user's preferred language(s) for the content. E.g., a user may run a Japanese browser, but prefers content in Arabic. Since the browser is enabled for many more languages that it is currently localized, this is not unusual. 909789 jaimejr 2001-09-08 09:00:36 -0700 Removing ME ---> barrowma (acting browser PM) 954474 security-bugs 2001-10-04 15:12:38 -0700 time marches on...retargeting to 0.9.6 1002017 security-bugs 2001-10-31 15:07:42 -0800 Moving to Moz1.0 as part of "paranoid mode" feature set 1054126 asa 2001-12-03 11:16:36 -0800 Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved) 1478109 security-bugs 2002-08-02 18:19:01 -0700 Futuring. 3553632 antoine.mechelynck 2008-03-30 11:26:50 -0700 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008033001 SeaMonkey/2.0a1pre Workaround: Set the pref general.useragent.locale (in about:config) to the empty string (or even to any language you want to spoof as using). If set to the empty string, the semicolon and one surrounding space are removed too. According to http://kb.mozillazine.org/General.useragent.locale , that pref was created on 2000-02-07. 3553876 ben.bucksch 2008-03-30 18:07:13 -0700 Per HTTP spec, "message which makes the user aware of the loss of privacy involved", i.e. not only user-configurable, but even an alert. (This applies all the more if this is set by default based on UI or OS language, like Firefox does.) 3851275 dveditz 2008-11-11 23:33:45 -0800 *** Bug 464414 has been marked as a duplicate of this bug. *** 4373809 xtc4uall 2009-10-31 07:55:12 -0700 *** Bug 525637 has been marked as a duplicate of this bug. *** 4373832 messi 2009-10-31 08:23:16 -0700 While I believe that my request (bug 525637) is a superset of this very old bug and not a duplicate I'd like to reactivate the topic here. Though it seems Mozilla is avoiding the topic. Also, setting the locale to blank is not a workaround because it will make you stand out even more. Please remove "has workaround" keyword. 4513456 matti 2010-01-30 07:50:00 -0800 *** Bug 543202 has been marked as a duplicate of this bug. *** 4640510 hsivonen 2010-04-15 07:15:44 -0700 Bug 543202 is also a superset and not an exact duplicate. For example, the Gecko build date is absolutely useless for any non-b.m.o sniffing but it makes UA strings have more fingerprintable parts. 4704138 hsivonen 2010-05-20 01:51:40 -0700 Note that CSS now exposes the directionality of the UI language. The HTML5 parser (via <isindex> prompt) exposes the UI language but not necessarily which regional variant when the string does not happen to vary by region. 4704196 ben.bucksch 2010-05-20 03:02:08 -0700 Both should instead use the *content* language (Prefs|Content|Language|Choose... , which is by default Firefox install the same as the UI language). The content language is fine to expose to the website, that's what it's for, and it's changeable independently. It's also more correct to use that, because the site should adjust based on that, and it would have wrong effects to have an English-UI Firefox nightly set to Arabic report left-to-right and "en" in some places and Arabic in Accept-Language. 4710031 gerv 2010-05-24 02:24:18 -0700 Are there _any_ known cases of a website using Accept-Language to infer someone's ethnicity and taking action against them, either electronic or physical? The only way to avoid that possibility would be to remove all language-identifying features from what the browser sends - Accept, JS, everything. However, these features are used today to provide serious and measurable benefits to web users, 99.999% of whom don't care if a site knows what languages they speak. Gerv 4710051 daniel 2010-05-24 02:58:44 -0700 (In reply to comment #68) > The only way to avoid that possibility would be to remove all > language-identifying features from what the browser sends - Accept, JS, > everything. However, these features are used today to provide serious and > measurable benefits to web users, 99.999% of whom don't care if a site knows > what languages they speak. I don't understand some of the comments above Gerv's... Ok, the spec says something, but pragmatism sometimes help if the spec is counter-productive There are many web sites out there that are tailored to serve me better, and that includes serve me in my own language if and when they support it. This is a hugely positive factor for all users around the world. Geolocating the IP address is not enough and many web sites have elaborated detection based on all what's available today, including user-agent string. Change that and you'll break their behaviour, and I won't call that "for the greatest benefit of all". I am myself strongly in favor of a wontfix for this bug unless the solution implemented is a "never reveal my language" pref in an advanced preference panel with default "on". And I'm not sure it's worth the bloat, honestly. 4710116 ben.bucksch 2010-05-24 04:57:00 -0700 Gerv, I am not opposed to Accept-Language at all, which is user-configurable and defaulted to the UI language. I think I said as much in my last message. I am opposed to the browser sending the *UI* language, where it's different from Accept-Language. Wherever we send the language, locale or country to the site, e.g. UserAgent string, it should be user-configurable value from Prefs|Content|Language|Choose... (which is already used for Accept-Language), not the UI language value. There is no loss for the user here. On the contrary, if anything it's going to work better. 4710119 ben.bucksch 2010-05-24 05:00:09 -0700 Please note that the summary of this bug specifically says "UI language", i.e. browser locale/ package, not "content language" = Accept-Language = "Prefs|Content|Language|Choose...". 4712043 hsivonen 2010-05-25 05:50:05 -0700 FWIW, I'm not really concerned about using language per se for nefarious purposes. I'm more concerned about UI language being yet another piece of configuration entropy that can be used for fingerprinting. See https://panopticlick.eff.org/ 4712114 ben.bucksch 2010-05-25 06:44:08 -0700 I'll update patch here as part of bug 57555, once I get to it. 4713583 gerv 2010-05-26 02:46:04 -0700 Ben: so you are not arguing for this switch from a privacy point of view, but a functionality one? If so, that does make sense to me. Gerv 4713599 ben.bucksch 2010-05-26 03:07:46 -0700 I argue from both perspectives. If the user is in control, there is no privacy issue, or at least no critical one. Also, reducing the number of permutations is good for functionality (consistent) and privacy (fingerprinting), in this case. 4714936 jstenback+bmo 2010-05-26 15:44:34 -0700 Not holding the 1.9.3 release for this bug. 4765188 gionnico 2010-06-24 18:34:52 -0700 I don't understand why should all locales but english one have something like it-it it;q=0.8 en-us;q=0.5 en;q=0.3 If I download italian, why is english there? And why two strings with different priorities (it-it and it)? This, by the way gives more information for fingerprinting than a plain "it" (this is in general more common than the double it-it) set as default for every italian build: official or unofficial and for every platform. 4765195 ben.bucksch 2010-06-24 18:38:31 -0700 gionnico, you're int he wrong bug. You talk about Accept-Language header, which is not subject of this bug. 4817593 460173 ben.bucksch 2010-07-25 15:00:03 -0700 Created attachment 460173 Patch 3: Change navigator.language to use Accept-Language After bug 572656 has fixed the UA string by removing the language part, this also fixes navigator.language. The property is retained (JS has no access to the Accept-Language header, to my knowledge), and retains the formal format, but uses the value from Accept-Language (which the user can freely configure in the pref window) instead of the UI language. Asking biesi to review. 4817595 ben.bucksch 2010-07-25 15:00:55 -0700 http://browserspy.dk/language.php http://browserspy.dk/showprop.php 4817605 460173 ben.bucksch 2010-07-25 15:15:57 -0700 Comment on attachment 460173 Patch 3: Change navigator.language to use Accept-Language Actually, bz reviewed bug 572656 4823687 460173 l10n 2010-07-28 06:43:27 -0700 Comment on attachment 460173 Patch 3: Change navigator.language to use Accept-Language Would this break on en-gb;q=0.8, en;q=0.7 Didn't dig into whitespace handling. Not that I'm in sync with the rationale of these bugs, for the record. 4824205 460173 bzbarsky 2010-07-28 10:20:04 -0700 Comment on attachment 460173 Patch 3: Change navigator.language to use Accept-Language Yeah, Axel's right. This needs to handle q values. And things like spaces around the ',' chars, etc. Probably best to just use nsCharSeparatedTokenizer and then deal with the q value thing. 4825360 ben.bucksch 2010-07-28 16:31:37 -0700 > This needs to handle q values. You mean I need to look for ";" in addition to ","? Yes, sure, sorry for the oversight. Will attach new patch. (I do not care to support *manually* hacked prefs that have a lesser preferred language as the first entry, if that's what you meant.) > nsCharSeparatedTokenizer Will take a look, how big the code will be with that and with FindInReadable(). 4830899 ben.bucksch 2010-07-31 05:11:33 -0700 Actually, the pref "intl.accept_languages" does not contains ;q= . The UI doesn't write q= in there, and if a user does, it's ignored and not sent in HTTP header, but the HTTP re-calculates the q=. Also, while nsCharSeparatedTokenizer is useful here, it seems to skip the first token. Either I don't know how to use its API, or the implementation is broken. 4830901 ben.bucksch 2010-07-31 05:13:39 -0700 > nsCharSeparatedTokenizer ... seems to skip the first token Nevermind, I was stupid. 4830904 461774 ben.bucksch 2010-07-31 05:16:55 -0700 Created attachment 461774 Patch 4: Change navigator.language to use Accept-Language 4831350 haqer 2010-07-31 16:53:01 -0700 I feel kinda bad for apparently slowing the approval of the patch down a bit, but I'd like to draw attention to a few things: 1. 3-char lang codes (need to be handled). Based on url mentioned in another bug, there are 2 existing examples of them: http://mxr.mozilla.org/l10n-mozilla1.9.2/search?string=intl.accept_languages&find=global/intl.properties (The same could be asked for 3-char country codes, but there are no examples of those, and they might not be probable (haven't looked into it).) 2. Default for messy accept-lang pref: should this be en-US rather than en for consistency w/ default en-US locale? I tend to think "yes". 3. Update urls: %LOCALE% in chrome prefs is resolved by navigator.language as of now, AFAIK. I'm 99.9% sure that the current UI language shouldn't be changed by an update based on preferred content language. If that's the case, then there needs to be an additional patch (in this bug or another), that accounts for necessary additional logic that is now required to substitute %LOCALE% in chrome app.update.url pref w/ UI lang, rather than navigator.language value. (Plus, I'm not 100% sure that an update in language B for an installation whose UI is in language A works smoothly every time: i'm not saying it doesn't either, but it would probably be something worth verifying if the updates were going to be based on the current preferred language.) 4. empty pref special case (messed up, or user wishes to not specify accept-language in HTTP): 4.1. should this result in navigator.language being empty, for consistency with HTTP Accept-Language? I tend to think "yes". 4.2. i'm also throwing this note in based on Java StringTokenizer's throwing an exception if nextElement() is called w/o hasMoreTokens() having returned true prior to that. Quick look at the source appears to suggest that nsCharSeparatedTokenizer works differently and (at least currently) returns an empty string instead. Forgive me for not having time to verify that, but i hope those who are already building FX 4 can take a quick look to make sure current empty pref handling wouldn't crash the app, for instance. Accounting for all of this should easy, except maybe item 3., which necessitates a patch for another class. P.S. For the record, I can't wait for this fix. 4831361 haqer 2010-07-31 17:20:38 -0700 Just noticed this as well: 5. Currently (FX <=3.6.x, country code in navigator.language is upper-case, whereas accept-language pref's country code is lower-case. Should navigator.language value be: 5.a. backwards compatible (this doesn't seem feasible, because some locales have country code in accept-lang, and no country code in navigator.language; either that's something sites will need to adjust to, or there'd need to be a map of first-accept-lang=ui-lang pairs based on FX 3.6.x used for 100% backwards-compatibility) or 5.b. upper-case or 5.c. lower-case IMHO, ideally 5.a., but 5.b. would be easier to implement and more consistent, at the expense of additional country code for some locales and/or case change for some locales (sorry, i haven't analyzed other locales for letter-case). If sites can adjust to UA format change for ALL locales, they can also adjust to navigator.language values changing slightly for SOME locales (but it might warrant a list of before-after values for affected locales). 4831373 haqer 2010-07-31 17:45:17 -0700 (In reply to comment #89) > 5.b. upper-case > or > 5.c. lower-case Clarification, I meant: 5.b. using upper-case country code or 5.c. using lower-case country code 4831382 mozbugz 2010-07-31 17:56:11 -0700 That can be addressed in another bug if it needs to be changed. 4831387 haqer 2010-07-31 18:03:51 -0700 (In reply to comment #88) > 3. Update urls: %LOCALE% in chrome prefs is resolved by navigator.language as > of now, AFAIK. I'm 99.9% sure that the current UI language shouldn't be changed > by an update based on preferred content language. If that's the case, then > there needs to be an additional patch (in this bug or another), that accounts > for necessary additional logic that is now required to substitute %LOCALE% in > chrome app.update.url pref w/ UI lang, rather than navigator.language value. Please ignore item 3.: a couple of my memory wires got crossed, and in fact no changes need to be made to app.update.url handling, because %LOCALE% there appears to be replaced based on the locale in update.locale file in app directory, and NOT based on navigator.language value. Unlike elsewhere, I acknowledge having wastefully posted 10 lines in c88 for item 3, and 6 lines here to clear that up. Also, to clarify, an obvious example for item 5 that i had in mind but didn't mention is en-US vs. en-us. 4831491 ben.bucksch 2010-07-31 22:36:59 -0700 Thanks for the comments, Reshat. 1. I was assuming only 2-char ISO lang codes were valid, but the HTTP spec explicitly gives examples with other codes, so I'll be more lax. I'll still check that the user didn't use the wrong Windows syntax of en_GB instead of the correct Internet syntax en-GB. 3. If we broke %LOCALE% in the updater, that'd be really bad. I'll double-check that this is not the case, as well as whether there are other stupid uses of navigator.language. 5. Yes, I was already thinking of casing, thanks for pointing out that the current navigator.language is en-US. I'll maybe just fix the casing, but only in cases of a 5-letter code (lowercase 2-letter, dash, uppercase 2-letter). Whether this is important also depends on other browsers. If they use different casing, likely sites will be tolerant (using .toLowerCase()). Specs: <http://asg.web.cmu.edu/rfc/rfc2616.html#sec-14.4> <https://developer.mozilla.org/en/Navigator.language> 4831492 ben.bucksch 2010-07-31 22:37:54 -0700 4. The fallback could be either "en" or "". I chose the former, but it's trivial to do the latter. Up to reviewer. *Informed* opinions welcome. 4831496 ben.bucksch 2010-07-31 22:53:33 -0700 Responding to self, I think it would indeed be better to use "" as fallback, esp. in light of "i-cherokee" as first accept-lang, and of sites in other countries which want to use the local language as fallback. When using "" as fallback, we leave the fallback to the site. When using "en", the site cannot differentiate whether it's a fallback or the user really meant English. So, I'll use "" as fallback. 4831745 l10n 2010-08-01 06:41:30 -0700 There's a good chance that we'll have script tags in language codes at some point, and maybe even x- stuff. 4831968 haqer 2010-08-01 11:27:02 -0700 (In reply to comment #88) > 2. Default for messy accept-lang pref: should this be en-US rather than en for > consistency w/ default en-US locale? I tend to think "yes". ... > 4. empty pref special case (messed up, or user wishes to not specify > accept-language in HTTP): > 4.1. should this result in navigator.language being empty, for consistency with > HTTP Accept-Language? I tend to think "yes". IMHO, "" navigator.language for "" accept-language is good. With regards to "" or afore-mentioned "en-US" navigator.language for messy/unrecognized accept-language, i'm not so sure, because accept-language header is not "" or "en-US" in this case as of now. I tend to think navigator.language should at least match the language in accept-language (allowing the (remote) possibility of not having a country code as it is the case in 3.6.x). So for "messed-up" intl.accept_languages, i'd either: 2.1. provide "messed-UP" as navigator.language, and keep HTTP accept-language as is (i.e., "messed-up") or 2.2. provide "" for both navigator.language and HTTP accept-language 2.3. provide "" for both navigator.language, and log a bug to do the same for HTTP accept-language Taking into account Axel's comment as well, 2.1 might be the best way to go in the context of this bug. If 2.2, or 2.3 were found desirable, IMHO we need a separate bug for that (especially, because exceptional manually set values are the subject of discussion here). 4834520 462244 ben.bucksch 2010-08-02 16:24:40 -0700 Created attachment 462244 Patch 5: Change navigator.language to use Accept-Language - removed the check, so now also allowing i-cherokee - return "", if the accept-lang pref is empty (or otherwise invalid) - replace _ with - (only first one for now) - return uppercase for en-US 4834539 ben.bucksch 2010-08-02 16:31:31 -0700 Searching for "navigator.language" in source returns (only): ./extensions/reporter/resources/content/reporter/reportWizard.js: const gParamLanguage = window.navigator.language; ./testing/extensions/community/chrome/content/litmus.js: this.locale = navigator.language; ./testing/sisyphus/tests/mozilla.org/download-page/userhook.js: data['005 navigator.language'] = navigator.language; I should fix these, too, but I will probably use bug 580032 as tracker for that. 4835057 bzbarsky 2010-08-02 22:07:50 -0700 Hmm. Why do we want to do the bits about converting '_' to '-' (how would the '_' get there?) and uppercasing stuff? 4835131 haqer 2010-08-02 23:33:13 -0700 IMHO, these points are worth another look: 4. IMHO, no assert is needed for empty accept-language, since RFC says: "If no Accept-Language header is present in the request, the server SHOULD assume that all languages are equally acceptable." Only affects debug builds, but still... 5. country code upper-casing: The following cases should be handled as well: abc-XY abc-XY-dialect https://wiki.mozilla.org/L10n:Locale_Codes https://wiki.mozilla.org/L10n:Teams One way of pseudocoding would be: if first '-' (at index 2 or 3), if any, is followed by no more than 2 alpha chars in a row, uppercase those 2 chars. That said, the whole item goes away if we are going to make country code in navigator.language lower-case, though that wouldn't be backwards-compatible. 4835137 l10n 2010-08-02 23:41:23 -0700 Please, don't use our wiki as a standard. The real document is http://tools.ietf.org/html/bcp47, which refers to http://tools.ietf.org/html/rfc4647 for the matching stuff. Here, http://tools.ietf.org/html/bcp47#section-2.1.1 rules: At all times, language tags and their subtags, including private use and extensions, are to be treated as case insensitive: there exist conventions for the capitalization of some of the subtags, but these MUST NOT be taken to carry meaning. 4835148 haqer 2010-08-02 23:50:41 -0700 Thanks, Axel. Well, i assumed we wanted consistency. If we are fine w/ en-US on one hand, and ast-es on the other, that's a different matter of course. If that is considered and decided to be OK, then that's the way it's gonna be. Still worth drawing attention to it, IMHO. 4835353 ben.bucksch 2010-08-03 03:31:49 -0700 > Hmm. Why do we want to do the bits about converting '_' to '-' > (how would the '_' get there?) and uppercasing stuff? 1. "-" vs. "_". The RFCs and ISO say that the separator is "-", e.g. "en-US". However, POSIX uses LANG="de_DE" in env vars, and Windows also uses the "en_US" notation. The latter is therefore common, and I've seen many people use "en_US" although the spec/protocol explicitly said "en-US", so it's a common error. How would it get there? By somebody editing the pref manually in <about:config>. The normal pref dialog does not allow to specify arbitrary tags. To avoid confusion and problems on the site's end, I want to prevent this, even if it's unlikely. I tried to make sure it's not a perf problem (just 2 int comparisons) nor a lot of code (just 2 lines). 2. uppercase: our pref contains e.g. "de-de,en-us,en", i.e. lower case. However, our locale codes are "de-DE", i.e. country part in upper case. BCP47 (mentioned by Axel above) also uses this notation in the examples. It's the convention. We used to return that as well, e.g. "en-US". If a site doesn't use navigator.language.toLowerCase(), the comparison will not fail. If our own code (comment 99) is any indication, this error is common, so if we don't adjust the casing to the convention, we may break stuff. Now, my parsing here is primitive. It works fine for the 2-letter-dash-2-letter codes that we use for locales, and IIRC that's all that the pref dialog allows currently, so it should work be sufficient currently. Only "failure" is indeed "ast-es" and similar codes with 3 letters as first part. BCP47 also gives examples: zh-Hant, de-Latn-DE, de-DE-x-goethe. For these, my code would return zh-HANT, de-LATN-DE, de-DE-X-GOETHE, which is not the convetional casing. If you think I should improve this, I would use the nsCharSeparator here as well, and then uppercase every 2-letter part, apart from the first part. 4835849 bzbarsky 2010-08-03 09:14:44 -0700 I guess my question is how far we're willing to go in terms of trying to canonicalize random input. I think the only two sources of this pref are: 1) What our prefs dialog generates. 2) What our localizers set up as the default for their locale. 3) about:config. I claim we don't care about #3, can impose any reasonable rules we want on #2, and fully control #1. So if it simplifies our code, we should just assume whatever we want and impose corresponding rules on #2. Axel, thoughts? 4835911 l10n 2010-08-03 09:47:50 -0700 rightly so 4836156 bzbarsky 2010-08-03 11:15:17 -0700 s/two sources/sources/, clearly. ;) 4837449 haqer 2010-08-03 18:50:27 -0700 Concise: IMHO, Ben's suggestion of uppercasing the first 2-letter part, after the first part, if any, might be ideal (though a bit harder to implement), but restricting such uppercasing to just the assumption that this 2-letter part is the second subtag (following 2- or 3-char first subtag), as i understand Boris and Axel appear to be inclined to do, will probably be sufficient for a long time (and might save x ms on each access?). If these are the 2 operational choices to proceed with, then choosing between them is almost a coin-toss situation IMHO. Verbose additional info: One could also say that we have 1 model, which is the intl.accept_languages chrome pref, whose value is presented by several views (in MVC pattern lingo). Paraphrasing Boris, the input can come from: i. pre-shipped intl.accept_languages pref values based on intl.properties (1) and 2)) ii. random about:config entries by the user (3)) FYI, if i enter "messed1-up,messed2-up" as random input, both prefs dialog and about:config reflect the same value (prefs dialog just shows them as codes in [] without displaying a recognized lang name in front of each value, although some pre-shipped values also don't have recognized lang names). 4837538 462638 ben.bucksch 2010-08-03 19:52:14 -0700 Created attachment 462638 Patch 6: Change navigator.language to use Accept-Language, using tokerizer for uppercasing Here's another patch with better uppercasing code. It uses the tokenizer for this as well, and uppercases all 2-letter parts, apart from the first one. 4837542 ben.bucksch 2010-08-03 19:57:18 -0700 > I claim we don't care about [<about:config>], can impose any reasonable rules > we want on [our prefs UI], and fully control [the defaults of the > localized builds]. So if it simplifies our code, we should just assume > whatever we want and impose corresponding rules on [the prefs UI]. OK, great, works for me. Only catch is: the intl.accept_languages pref may have existing values. So, even if we change the prefs UI, the old values are still there. And unfortunately, they are in "de-de" notation. So, unless you want to migrate, we have to work with that. I attached another patch with better lang part parsing. Make your pick. I'd take patch 6. 4837601 462638 bzbarsky 2010-08-03 20:49:30 -0700 Comment on attachment 462638 Patch 6: Change navigator.language to use Accept-Language, using tokerizer for uppercasing I still think the uppercasing is silly, but r=me if you s/PRBool/bool/ for that thing you assign bools into. 4837612 462638 ben.bucksch 2010-08-03 20:56:27 -0700 Comment on attachment 462638 Patch 6: Change navigator.language to use Accept-Language, using tokerizer for uppercasing what happens with sr? 4837619 462663 ben.bucksch 2010-08-03 21:03:01 -0700 Created attachment 462663 Patch 7: Change navigator.language to use Accept-Language Playing Boules with bool and PRBool. 4837679 462663 bzbarsky 2010-08-03 21:51:22 -0700 Comment on attachment 462663 Patch 7: Change navigator.language to use Accept-Language Let's have jst do that. 4842897 462663 jstenback+bmo 2010-08-05 15:19:37 -0700 Comment on attachment 462663 Patch 7: Change navigator.language to use Accept-Language + while (localeTokenizer.hasMoreTokens()) + { + const nsSubstring &code = localeTokenizer.nextToken(); + if (code.Length() == 2 && !first) + { + nsAutoString upper(code); + ::ToUpperCase(upper); + aLanguage.Replace(pos, code.Length(), upper); + } + pos += code.Length() + 1; // 1 is the separator + if (first) + first = false; Might as well loose the if check there, the result will be the same w/o it and with less branching and less code. sr=jst 4909787 kairo 2010-09-02 05:52:31 -0700 That bug basically means decreased usability for people on our website, as we can't offer the correct locale download matching the browser version they are using right now any more. Thanks for breaking us. 4909801 ben.bucksch 2010-09-02 05:57:41 -0700 KaiRo, wrong. Just use Accept-Language. That's the standard and what you should have used anyway. 4909812 kairo 2010-09-02 06:03:14 -0700 (In reply to comment #117) > KaiRo, wrong. Just use Accept-Language. That's the standard and what you should > have used anyway. Completely wrong. I don't give a damn about the preferred language of *web sites* for that user (and that's what Accept-Language is), I only care about the *UI language* he is using. If I can't match that, I probably should even think about trying about giving the user any specific preferred download but send him through a hurdle run of clicks to select it himself. Very user friendly, but thank you for giving me no other choice. 4909860 daniel 2010-09-02 06:28:08 -0700 (In reply to comment #118) > Completely wrong. I don't give a damn about the preferred language of *web > sites* for that user (and that's what Accept-Language is), I only care about > the *UI language* he is using. If I can't match that, I probably should even > think about trying about giving the user any specific preferred download but > send him through a hurdle run of clicks to select it himself. Very user > friendly, but thank you for giving me no other choice. Guys, you are _both_ right. Ben want to follow an IETF recommendation on a privacy issue and KaiRo wants to match the UI language because that's the only way he can serve correctly someone like me, ie someone browsing the web in french when it's available but using only en-US software. That said, KaiRo, I think the vast majority of internet users use a browser UI locale matching the accept-language's topmost language, and only a small minority of geeks have a different configuration. Let me ask a naive question here: if I download a given localized version of Firefox, is the Accept-Language set by default to match that language? If yes, then at least KaiRo can rely on that for, again, the vast majority of users. The minority of übergeeks will be annoyed a bit but hey we're always annoyed by everything aren't we? FWIW, I still think the war-on-privacy-issues goes too far here. Anyway... 4909884 dao+bmo 2010-09-02 06:35:03 -0700 (In reply to comment #119) > Let me ask a naive question here: if I download a given localized version of > Firefox, is the Accept-Language set by default to match that language? Yes. FWIW, this isn't just fixing a privacy issue. It's also about making navigator.language more useful when it's used on the client side very much like Accept-Language would be used on the server side. 4909887 ben.bucksch 2010-09-02 06:36:01 -0700 > if I download a given localized version of > Firefox, is the Accept-Language set by default to match that language? For the big locales, yes. For some small locales, there may be differences. Yes, the download button detecting system and language is only for a good default, to make it easier for the majority of users. I think a link/page "Other languages and systems", like Firefox has, should solve this for the most part. 4909893 kairo 2010-09-02 06:40:36 -0700 (In reply to comment #119) > Let me ask a naive question here: if I download a given localized version of > Firefox, is the Accept-Language set by default to match that language? Fully depends on the localizers, but usually, the UA language is *among* the value in Accept-Language, even if some carefully chosen variant of it might be the primary language listed there. Also, the user might change the Accept-Language at will, making it way more fingerprintable than the UI locale, and e.g. possible making "ger-saxon" their primary Accept-Language header when using a German (de) build, i.e. having an Accept-Language header including all of ger-saxon, de-DE, de, and possibly even en-US and/or en. > The minority of übergeeks will be annoyed a bit but hey we're always annoyed > by everything aren't we? At least by all the paranoia going on with some things like the so-called "privacy" or "fingerprinting" threats introduced by UA strings. And I'm very sensible about privacy matters usually, but there are clearly things where we are overdoing it while at the same time not working on stuff that ought to be much higher priority but may have higher impact overall, like the exposure of the plugin or installed font lists to the web, which are way more fingerprintable than ridiculous things like the UI languages or using a nightly. 4909896 l10n 2010-09-02 06:42:14 -0700 In most cases, the first accept locale differs from the chosen locale. Maybe just in that it's de-de instead of de, or upper vs lower case things that folks reading locale-code specs should already deal with, but it's not exactly the same thing. http://mxr.mozilla.org/l10n-mozilla1.9.2/search?string=intl.accept_languages&find=global/intl.properties for data. 4909897 kairo 2010-09-02 06:42:51 -0700 In any case, as I can't be bothered to write a heuristic parser for that new stupid property, I'll just offer en-US builds when that locale doesn't give an exact match with one of the locales we can offer, everyone else needs to use the the "other platforms and languages link". Who needs usability anyhow. 4909941 ben.bucksch 2010-09-02 07:11:33 -0700 > usually, the UA language is *among* the value in Accept-Language So, it's solvable. You can detect which UI locale the build is, and offer the right download, in most cases (98%? of users) at least. The others can fall back to "other languages". 4909954 kairo 2010-09-02 07:20:28 -0700 (In reply to comment #125) > > usually, the UA language is *among* the value in Accept-Language > > So, it's solvable. You can detect which UI locale the build is, and offer the > right download, in most cases (98%? of users) at least. Only if I build a parser for the Accept-Languages list, which is quite some work for a simple download box... 4909971 ben.bucksch 2010-09-02 07:31:12 -0700 fairly simple: var localeMapping = { "de-de" : "de", "fo-ba" : "ba", ... } var useLocale = "unknown"; for each (var entry in acceptLang.split(",")) { // separate langs // strip q and spaces let lang = entry.replace(/;.*/, "").replace(" ", "").toLowerCase(); if (localeMapping[lang]) { useLocale = localeMapping[lang]; break; } } if (useLocale == "unknown") { showOtherLangsInBiggerFont(); // or directly on page useLocale = "en-US"; } var downloadURL = mirror + "seamonkey-" + currentVersion + "-" + platformSpec + "-" + useLocale + platformExtension; That's 12 lines of JS code, plus the mapping (which is fairly static). It won't be much more in PHP or whatever you use on the website, if you want to do it there instead. 4910002 pascalc 2010-09-02 07:47:36 -0700 kairo, for PHP you can use my locale detection class: http://granary.stage.mozilla.com/libs/l10n-demos/localeDetectionDemo.php 4910128 l10n 2010-09-02 08:37:39 -0700 FTR, both ignore script tags, which we'll apparently not get for 4.0, but that are totally fine to use (not that we have UI for those). 4913769 dwitte 2010-09-03 13:27:18 -0700 Should we get a followup bug for removing the 'general.useragent.locale' pref from all.js and nuking the corresponding code/API in nsHttpHandler? 4913935 l10n 2010-09-03 14:44:38 -0700 We don't have to have some pref to select the chrome locale, and I don't see a good argument for dropping this one. 4913968 dwitte 2010-09-03 14:59:54 -0700 Sorry, I don't follow -- you're saying it's unnecessary but you want to keep it? What useful information does it provide? 4914691 dao+bmo 2010-09-04 01:11:17 -0700 (In reply to comment #130) > Should we get a followup bug for [...] nuking the corresponding code/API in nsHttpHandler? 4915155 haqer 2010-09-04 12:32:20 -0700 (In reply to comment #116) > That bug basically means decreased usability for people on our website, as we > can't offer the correct locale download matching the browser version they are > using right now any more. It would also be more convenient if people had their name, and their preferred language written on their foreheads. Yet, somehow, i don't think i would want to be one of those people, and i think the majority of people wouldn't be either. It's not all about convenience and usability. There are trade-offs, and cost-benefit analyses involved. (In reply to comment #130) > Should we get a followup bug for removing the 'general.useragent.locale' pref > from all.js and nuking the corresponding code/API in nsHttpHandler? I think the pref might be used by some add-ons that provide UI for switching between more than 2 langpacks. Not sure if this is still workable in FF 4... That said, http should no longer have anything to do w/ this pref. If it stays, it should only be for manual or addon-based UI locale manipulation. 4915936 djcater+bugzilla 2010-09-05 09:03:43 -0700 I don't understand comment 131 or comment 133. 4915939 l10n 2010-09-05 09:06:09 -0700 (In reply to comment #131) > We don't have to have some pref to select the chrome locale, and I don't see a > good argument for dropping this one. Can't type. We do have to have some pref to select the chrome locale, and I don't see a good argument for dropping g.u.locale. 4916129 dwitte 2010-09-05 13:01:09 -0700 It's now misnamed, that's all. We can leave the name as-is but we should probably remove the API for reading it on nsHttpHandler, because that doesn't belong there anymore. 5046142 benjamin 2010-10-29 14:06:42 -0700 Please wait until after we branch. 5375477 ehsan.akhgari 2011-03-28 14:03:24 -0700 I do not feel comfortable taking this on cedar. Please land this on mozilla-central when it's ready 5379960 dao+bmo 2011-03-30 04:37:30 -0700 http://hg.mozilla.org/mozilla-central/rev/ead683169ef2 5379962 dao+bmo 2011-03-30 04:38:44 -0700 *** Bug 580032 has been marked as a duplicate of this bug. *** 5380002 ben.bucksch 2011-03-30 05:06:47 -0700 Thanks, Dao, for commiting! 5380023 ben.bucksch 2011-03-30 05:26:58 -0700 (hihi. Almost 10 years after my first patch here. Do I get a prize? :) ) 5380657 shawn.sumin 2011-03-30 10:05:14 -0700 @Ben: You get a Cookie (Brand name: Privacy Cookies). Congratz. 5380713 ben.bucksch 2011-03-30 10:19:10 -0700 nomnomnom 5423113 jorgev 2011-04-20 18:11:15 -0700 sheppy, I think this might be important for add-on developers and worthwhile documenting. Thanks! 5424109 the.sheppy 2011-04-21 08:44:30 -0700 Documentation updated: https://developer.mozilla.org/en/DOM/window.navigator.language Also mentioned on Firefox 5 for developers. 5463432 asa 2011-05-11 11:50:29 -0700 not interested for 5. 5463439 the.sheppy 2011-05-11 11:51:46 -0700 I thought this landed already on Aurora. Did it not? 5463473 benjamin 2011-05-11 11:57:37 -0700 Looks like it did, but release drivers still have no reason to track it in particular at this point. 43864 2001-07-27 19:36:28 -0700 2010-07-25 15:02:54 -0700 Proposed Fix for UA-string. Also contains Win fix for bug 57555. 55366-1.diff text/plain 4401 ben.bucksch PyA1NTM2Ni0xLmRpZmYKSW5kZXg6IG5zSHR0cEhhbmRsZXIuY3BwCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZp bGU6IC9jdnNyb290L21vemlsbGEvbmV0d2Vyay9wcm90b2NvbC9odHRwL3NyYy9uc0h0dHBIYW5k bGVyLmNwcCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xNgpkaWZmIC11IC13IC1yMS4xNiBuc0h0 dHBIYW5kbGVyLmNwcAotLS0gbnNIdHRwSGFuZGxlci5jcHAJMjAwMS8wNi8yMCAwMToyMTo0Mgkx LjE2CisrKyBuc0h0dHBIYW5kbGVyLmNwcAkyMDAxLzA3LzI4IDAyOjIyOjIxCkBAIC0xMjgsOCAr MTI4LDYgQEAKICAgICAgICAgICAgICAgICBuc0h0dHBIYW5kbGVyOjpQcmVmc0NhbGxiYWNrLCAo dm9pZCopdGhpcyk7CiAgICAgICAgIG1QcmVmcy0+VW5yZWdpc3RlckNhbGxiYWNrKElOVExfQUND RVBUX0NIQVJTRVQsIAogICAgICAgICAgICAgICAgIG5zSHR0cEhhbmRsZXI6OlByZWZzQ2FsbGJh Y2ssICh2b2lkKil0aGlzKTsKLSAgICAgICAgbVByZWZzLT5VbnJlZ2lzdGVyQ2FsbGJhY2soVUFf UFJFRl9QUkVGSVggImxvY2FsZSIsIAotICAgICAgICAgICAgICAgIG5zSHR0cEhhbmRsZXI6OlBy ZWZzQ2FsbGJhY2ssICh2b2lkKil0aGlzKTsKICAgICAgICAgbVByZWZzLT5VbnJlZ2lzdGVyQ2Fs bGJhY2soVUFfUFJFRl9QUkVGSVggIm1pc2MiLAogICAgICAgICAgICAgICAgIG5zSHR0cEhhbmRs ZXI6OlByZWZzQ2FsbGJhY2ssICh2b2lkICopdGhpcyk7CiAgICAgfQpAQCAtMjEzLDggKzIxMSw2 IEBACiAgICAgICAgICAgICBuc0h0dHBIYW5kbGVyOjpQcmVmc0NhbGxiYWNrLCAodm9pZCopdGhp cyk7CiAgICAgbVByZWZzLT5SZWdpc3RlckNhbGxiYWNrKElOVExfQUNDRVBUX0NIQVJTRVQsIAog ICAgICAgICAgICAgbnNIdHRwSGFuZGxlcjo6UHJlZnNDYWxsYmFjaywgKHZvaWQqKXRoaXMpOwot ICAgIG1QcmVmcy0+UmVnaXN0ZXJDYWxsYmFjayhVQV9QUkVGX1BSRUZJWCAibG9jYWxlIiwgCi0g ICAgICAgICAgICBuc0h0dHBIYW5kbGVyOjpQcmVmc0NhbGxiYWNrLCAodm9pZCopdGhpcyk7CiAg ICAgbVByZWZzLT5SZWdpc3RlckNhbGxiYWNrKFVBX1BSRUZfUFJFRklYICJtaXNjIiwKICAgICAg ICAgICAgIG5zSHR0cEhhbmRsZXI6OlByZWZzQ2FsbGJhY2ssICh2b2lkICopdGhpcyk7CiAKQEAg LTkzMCwxMiArOTI2LDEyIEBACiAgICAgaWYgKCFtU2VjdXJpdHkpCiAgICAgICAgIG1TZWN1cml0 eS5BZG9wdChuc0NSVDo6c3RyZHVwKFVBX0FQUFNFQ1VSSVRZX0ZBTExCQUNLKSk7CiAKLSAgICAv LyBHYXRoZXIgbG9jYWxlLgotICAgIG5zWFBJRExTdHJpbmcgdXZhbDsKLSAgICBtUHJlZnMtPkdl dExvY2FsaXplZFVuaWNoYXJQcmVmKFVBX1BSRUZfUFJFRklYICJsb2NhbGUiLCAKLSAgICAgICAg Z2V0dGVyX0NvcGllcyh1dmFsKSk7Ci0gICAgaWYgKHV2YWwpCi0gICAgICAgIG1MYW5ndWFnZS5B ZG9wdChUb05ld1VURjhTdHJpbmcobnNEZXBlbmRlbnRTdHJpbmcodXZhbCkpKTsKKyAgICBtTGFu Z3VhZ2UuQWRvcHQobnNDUlQ6OnN0cmR1cCgiZW4iKSk7CisgICAgICAgICAgICAgICAgICAgICAg LyogZHVtbXkuIFNlZSBidWcgNTUzNjYuCisgICAgICAgICAgICAgICAgICAgICAgICAgV2UgY291 bGQgdXNlIHRoZSBhY2NlcHQtbGFuZyBwcmVmIGhlcmUsIGJ1dAorICAgICAgICAgICAgICAgICAg ICAgICAgIHdoeSBzaG91bGQgd2UgYm90aGVyPyBJIGRvbid0IHRoaW5rLCBtYW55IHNpdGVzCisg ICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGx5IGNoZWNrIHRoaXMgdmFsdWUsIGFuZCB0 aGV5ICpzaG91bGQqIHVzZSB0aGUKKyAgICAgICAgICAgICAgICAgICAgICAgICBBY2NlcHQtTGFu Z3VhZ2UgaGVhZGVyIGFueXdheS4gKi8KIAogICAgICAgLy8gR2F0aGVyIHBsYXRmb3JtLgogICAg IG1QbGF0Zm9ybS5BZG9wdChuc0NSVDo6c3RyZHVwKApAQCAtOTcyLDM2ICs5NjgsMTUgQEAKICAg ICBPU1ZFUlNJT05JTkZPIGluZm8gPSB7IHNpemVvZiBPU1ZFUlNJT05JTkZPIH07CiAgICAgaWYg KEdldFZlcnNpb25FeCgmaW5mbykpIHsKICAgICAgICAgaWYgKGluZm8uZHdQbGF0Zm9ybUlkID09 IFZFUl9QTEFURk9STV9XSU4zMl9OVCkgewotICAgICAgICAgICAgaWYgKGluZm8uZHdNYWpvclZl cnNpb24gICAgICA9PSAzKQotICAgICAgICAgICAgICAgIG1Pc2NwdS5BZG9wdChuc0NSVDo6c3Ry ZHVwKCJXaW5OVDMuNTEiKSk7Ci0gICAgICAgICAgICBlbHNlIGlmIChpbmZvLmR3TWFqb3JWZXJz aW9uID09IDQpCi0gICAgICAgICAgICAgICAgbU9zY3B1LkFkb3B0KG5zQ1JUOjpzdHJkdXAoIldp bk5UNC4wIikpOwotICAgICAgICAgICAgZWxzZSB7Ci0gICAgICAgICAgICAgICAgY2hhciAqYnVm ID0gUFJfc21wcmludGYoIldpbmRvd3MgTlQgJWxkLiVsZCIsCi0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgaW5mby5kd01ham9yVmVyc2lvbiwKLSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBpbmZvLmR3TWlub3JWZXJzaW9uKTsKLSAgICAgICAg ICAgICAgICBpZiAoYnVmKSB7Ci0gICAgICAgICAgICAgICAgICAgIG1Pc2NwdS5BZG9wdChuc0NS VDo6c3RyZHVwKGJ1ZikpOwotICAgICAgICAgICAgICAgICAgICBQUl9zbXByaW50Zl9mcmVlKGJ1 Zik7Ci0gICAgICAgICAgICAgICAgfQotICAgICAgICAgICAgfQorICAgICAgICAgIG1Pc2NwdS5B ZG9wdChuc0NSVDo6c3RyZHVwKCJXaW5OVCIpKTsKICAgICAgICAgfSBlbHNlIGlmIChpbmZvLmR3 UGxhdGZvcm1JZCA9PSBWRVJfUExBVEZPUk1fV0lOMzJfV0lORE9XUyAmJgogICAgICAgICAgICAg ICAgICAgIGluZm8uZHdNYWpvclZlcnNpb24gPT0gNCkgewotICAgICAgICAgICAgaWYgKGluZm8u ZHdNaW5vclZlcnNpb24gPT0gOTApCi0gICAgICAgICAgICAgICAgbU9zY3B1LkFkb3B0KG5zQ1JU OjpzdHJkdXAoIldpbiA5eCA0LjkwIikpOyAgLy8gV2luZG93cyBNZQotICAgICAgICAgICAgZWxz ZSBpZiAoaW5mby5kd01pbm9yVmVyc2lvbiA+IDApCi0gICAgICAgICAgICAgICAgbU9zY3B1LkFk b3B0KG5zQ1JUOjpzdHJkdXAoIldpbjk4IikpOwotICAgICAgICAgICAgZWxzZQotICAgICAgICAg ICAgICAgIG1Pc2NwdS5BZG9wdChuc0NSVDo6c3RyZHVwKCJXaW45NSIpKTsKKyAgICAgICAgICBt T3NjcHUuQWRvcHQobnNDUlQ6OnN0cmR1cCgiV2luOXgiKSk7CiAgICAgICAgIH0gZWxzZSB7Ci0g ICAgICAgICAgICBjaGFyICpidWYgPSBQUl9zbXByaW50ZigiV2luZG93cyAlbGQuJWxkIiwKLSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZm8uZHdNYWpvclZlcnNpb24sCi0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbmZvLmR3TWlub3JWZXJzaW9uKTsK LSAgICAgICAgICAgIGlmIChidWYpIHsKLSAgICAgICAgICAgICAgICBtT3NjcHUuQWRvcHQobnND UlQ6OnN0cmR1cChidWYpKTsKLSAgICAgICAgICAgICAgICBQUl9zbXByaW50Zl9mcmVlKGJ1Zik7 Ci0gICAgICAgICAgICB9CisgICAgICAgICAgbU9zY3B1LkFkb3B0KG5zQ1JUOjpzdHJkdXAoIldp biIpKTsKICAgICAgICAgfQorICAgIH0gZWxzZSB7CisgICAgICBtT3NjcHUuQWRvcHQobnNDUlQ6 OnN0cmR1cCgiV2luIikpOwogICAgIH0KICNlbGlmIGRlZmluZWQgKFhQX1VOSVgpIHx8IGRlZmlu ZWQgKFhQX0JFT1MpCiAgICAgc3RydWN0IHV0c25hbWUgbmFtZTsKQEAgLTExNjAsMTcgKzExMzUs NiBAQAogICAgICAgICAgICAgbVVzZXJBZ2VudElzRGlydHkgPSBQUl9UUlVFOwogICAgICAgICB9 CiAgICAgICAgIE5TX0FTU0VSVElPTighdGVtcCwgInRyb3VibGU6IHxDb3B5Q2hhclByZWZ8IGZh aWxlZCwgYnV0IHJldHVybmVkIGEgc3RyaW5nIGFueXdheSEiKTsKLSAgICB9Ci0KLSAgICBpZiAo YkNoYW5nZWRBbGwgfHwgUExfc3RyY21wKHByZWYsIFVBX1BSRUZfUFJFRklYICJsb2NhbGUiKSA9 PSAwKSB7Ci0gICAgICAgIC8vIDU1MTU2OiByZS1HYXRoZXIgbG9jYWxlLgotICAgICAgICBuc1hQ SURMU3RyaW5nIHV2YWw7Ci0gICAgICAgIHJ2ID0gbVByZWZzLT5HZXRMb2NhbGl6ZWRVbmljaGFy UHJlZihVQV9QUkVGX1BSRUZJWCAibG9jYWxlIiwgCi0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBnZXR0ZXJfQ29waWVzKHV2YWwpKTsKLSAgICAgICAgaWYgKE5T X1NVQ0NFRURFRChydikpIHsKLSAgICAgICAgICAgIG1MYW5ndWFnZS5BZG9wdChUb05ld1VURjhT dHJpbmcobnNEZXBlbmRlbnRTdHJpbmcodXZhbCkpKTsKLSAgICAgICAgICAgIG1Vc2VyQWdlbnRJ c0RpcnR5ID0gUFJfVFJVRTsKLSAgICAgICAgfQogICAgIH0KIAogICAgIC8vIGdlbmVyYWwudXNl cmFnZW50Lm1pc2MK 460173 2010-07-25 15:00:03 -0700 2010-07-31 05:16:55 -0700 Patch 3: Change navigator.language to use Accept-Language lang-js-55366-3.diff text/plain 1769 ben.bucksch ZGlmZiAtLWdpdCBhL2RvbS9iYXNlL25zR2xvYmFsV2luZG93LmNwcCBiL2RvbS9iYXNlL25zR2xv YmFsV2luZG93LmNwcAotLS0gYS9kb20vYmFzZS9uc0dsb2JhbFdpbmRvdy5jcHAKKysrIGIvZG9t L2Jhc2UvbnNHbG9iYWxXaW5kb3cuY3BwCkBAIC05ODU0LDI5ICs5ODU0LDM5IEBAIG5zTmF2aWdh dG9yOjpHZXRBcHBOYW1lKG5zQVN0cmluZyYgYUFwcE4KICAgICAgIHJldHVybiBOU19PSzsKICAg ICB9CiAgIH0KIAogICBhQXBwTmFtZS5Bc3NpZ25MaXRlcmFsKCJOZXRzY2FwZSIpOwogICByZXR1 cm4gTlNfT0s7CiB9CiAKKy8qKgorICogVGFrZSBmaXJzdCB2YWx1ZSBmcm9tIEFjY2VwdC1MYW5n dWFnZXMgKEhUVFAgaGVhZGVyKSwgd2hpY2ggaXMKKyAqIHRoZSAiY29udGVudCBsYW5ndWFnZSIg ZnJlZWx5IHNldCBieSB0aGUgdXNlciBpbiB0aGUgUHJlZiB3aW5kb3cuCisgKiBTZWUgUkZDIDI2 MTYsIFNlY3Rpb24gMTUuMS40ICJQcml2YWN5IElzc3VlcyBDb25uZWN0ZWQgdG8gQWNjZXB0IEhl YWRlcnMiCisgKi8KIE5TX0lNRVRIT0RJTVAKIG5zTmF2aWdhdG9yOjpHZXRMYW5ndWFnZShuc0FT dHJpbmcmIGFMYW5ndWFnZSkKIHsKLSAgbnNyZXN1bHQgcnY7Ci0gIG5zQ09NUHRyPG5zSUh0dHBQ cm90b2NvbEhhbmRsZXI+Ci0gICAgc2VydmljZShkb19HZXRTZXJ2aWNlKE5TX05FVFdPUktfUFJP VE9DT0xfQ09OVFJBQ1RJRF9QUkVGSVggImh0dHAiLCAmcnYpKTsKLSAgaWYgKE5TX1NVQ0NFRURF RChydikpIHsKLSAgICBuc0NBdXRvU3RyaW5nIGxhbmc7Ci0gICAgcnYgPSBzZXJ2aWNlLT5HZXRM YW5ndWFnZShsYW5nKTsKLSAgICBDb3B5QVNDSUl0b1VURjE2KGxhbmcsIGFMYW5ndWFnZSk7Ci0g IH0KLQotICByZXR1cm4gcnY7CisgIC8vIGUuZy4gImRlLWRlLGVuLXVzLGVuIgorICBjb25zdCBu c0Fkb3B0aW5nU3RyaW5nJiBhY2NlcHRMYW5nID0KKyAgICAgIG5zQ29udGVudFV0aWxzOjpHZXRM b2NhbGl6ZWRTdHJpbmdQcmVmKCJpbnRsLmFjY2VwdF9sYW5ndWFnZXMiKTsKKyAgLy8gdGFrZSBl dmVyeXRoaW5nIGJlZm9yZSB0aGUgZmlyc3QgIiwiCisgIG5zQVN0cmluZzo6Y29uc3RfaXRlcmF0 b3Igc3RhcnRTdHJpbmcsIHN0YXJ0Q29tbWEsIGVuZENvbW1hOworICBhY2NlcHRMYW5nLkJlZ2lu UmVhZGluZyhzdGFydFN0cmluZyk7CisgIGFjY2VwdExhbmcuQmVnaW5SZWFkaW5nKHN0YXJ0Q29t bWEpOworICBhY2NlcHRMYW5nLkVuZFJlYWRpbmcoZW5kQ29tbWEpOworICBpZiAoRmluZEluUmVh ZGFibGUoTlNfTElURVJBTF9TVFJJTkcoIiwiKSwgc3RhcnRDb21tYSwgZW5kQ29tbWEpKQorICAg IGFMYW5ndWFnZS5Bc3NpZ24oU3Vic3RyaW5nKHN0YXJ0U3RyaW5nLCBzdGFydENvbW1hKSk7Cisg IGVsc2UKKyAgICBhTGFuZ3VhZ2UuQXNzaWduKGFjY2VwdExhbmcpOworICBOU19BU1NFUlRJT04o YUxhbmd1YWdlLkxlbmd0aCgpID09IDIgfHwgYUxhbmd1YWdlLkxlbmd0aCgpID09IDUsCisgICAg ICAiaW52YWxpZCBpbnRsLmFjY2VwdF9sYW5ndWFnZXMgcHJlZiIpOworICByZXR1cm4gTlNfT0s7 CiB9CiAKIE5TX0lNRVRIT0RJTVAKIG5zTmF2aWdhdG9yOjpHZXRQbGF0Zm9ybShuc0FTdHJpbmcm IGFQbGF0Zm9ybSkKIHsKICAgaWYgKCFuc0NvbnRlbnRVdGlsczo6SXNDYWxsZXJUcnVzdGVkRm9y UmVhZCgpKSB7CiAgICAgY29uc3QgbnNBZG9wdGluZ0NTdHJpbmcmIG92ZXJyaWRlID0KICAgICAg IG5zQ29udGVudFV0aWxzOjpHZXRDaGFyUHJlZigiZ2VuZXJhbC5wbGF0Zm9ybS5vdmVycmlkZSIp Owo= 461774 2010-07-31 05:16:55 -0700 2010-08-02 16:24:40 -0700 Patch 4: Change navigator.language to use Accept-Language lang-js-55366-4.diff text/plain 2374 ben.bucksch ZGlmZiAtLWdpdCBhL2RvbS9iYXNlL25zR2xvYmFsV2luZG93LmNwcCBiL2RvbS9iYXNlL25zR2xv YmFsV2luZG93LmNwcAotLS0gYS9kb20vYmFzZS9uc0dsb2JhbFdpbmRvdy5jcHAKKysrIGIvZG9t L2Jhc2UvbnNHbG9iYWxXaW5kb3cuY3BwCkBAIC02MiwxNiArNjIsMTcgQEAKICNpbmNsdWRlICJu c1hQSURMU3RyaW5nLmgiCiAjaW5jbHVkZSAibnNKU1V0aWxzLmgiCiAjaW5jbHVkZSAicHJtZW0u aCIKICNpbmNsdWRlICJqc2FwaS5oIiAgICAgICAgICAgICAgLy8gZm9yIEpTQXV0b1JlcXVlc3QK ICNpbmNsdWRlICJqc2RiZ2FwaS5oIiAgICAgICAgICAgLy8gZm9yIEpTX0NsZWFyV2F0Y2hQb2lu dHNGb3JPYmplY3QKICNpbmNsdWRlICJuc1JlYWRhYmxlVXRpbHMuaCIKICNpbmNsdWRlICJuc0RP TUNsYXNzSW5mby5oIgogI2luY2x1ZGUgIm5zQ29udGVudFV0aWxzLmgiCisjaW5jbHVkZSAibnND aGFyU2VwYXJhdGVkVG9rZW5pemVyLmgiIC8vIGZvciBBY2NlcHQtTGFuZ3VhZ2UgcGFyc2luZwog CiAvLyBPdGhlciBDbGFzc2VzCiAjaW5jbHVkZSAibnNJRXZlbnRMaXN0ZW5lck1hbmFnZXIuaCIK ICNpbmNsdWRlICJuc0VzY2FwZS5oIgogI2luY2x1ZGUgIm5zU3R5bGVDb29yZC5oIgogI2luY2x1 ZGUgIm5zTWltZVR5cGVBcnJheS5oIgogI2luY2x1ZGUgIm5zTmV0VXRpbC5oIgogI2luY2x1ZGUg Im5zSUNhY2hpbmdDaGFubmVsLmgiCkBAIC05ODU0LDI5ICs5ODU1LDM5IEBAIG5zTmF2aWdhdG9y OjpHZXRBcHBOYW1lKG5zQVN0cmluZyYgYUFwcE4KICAgICAgIHJldHVybiBOU19PSzsKICAgICB9 CiAgIH0KIAogICBhQXBwTmFtZS5Bc3NpZ25MaXRlcmFsKCJOZXRzY2FwZSIpOwogICByZXR1cm4g TlNfT0s7CiB9CiAKKy8qKgorICogSlMgcHJvcGVydHkgbmF2aWdhdG9yLmxhbmd1YWdlLCBleHBv c2VkIHRvIHdlYiBjb250ZW50LgorICogVGFrZSBmaXJzdCB2YWx1ZSBmcm9tIEFjY2VwdC1MYW5n dWFnZXMgKEhUVFAgaGVhZGVyKSwgd2hpY2ggaXMKKyAqIHRoZSAiY29udGVudCBsYW5ndWFnZSIg ZnJlZWx5IHNldCBieSB0aGUgdXNlciBpbiB0aGUgUHJlZiB3aW5kb3cuCisgKiBTZWUgUkZDIDI2 MTYsIFNlY3Rpb24gMTUuMS40ICJQcml2YWN5IElzc3VlcyBDb25uZWN0ZWQgdG8gQWNjZXB0IEhl YWRlcnMiCisgKi8KIE5TX0lNRVRIT0RJTVAKIG5zTmF2aWdhdG9yOjpHZXRMYW5ndWFnZShuc0FT dHJpbmcmIGFMYW5ndWFnZSkKIHsKLSAgbnNyZXN1bHQgcnY7Ci0gIG5zQ09NUHRyPG5zSUh0dHBQ cm90b2NvbEhhbmRsZXI+Ci0gICAgc2VydmljZShkb19HZXRTZXJ2aWNlKE5TX05FVFdPUktfUFJP VE9DT0xfQ09OVFJBQ1RJRF9QUkVGSVggImh0dHAiLCAmcnYpKTsKLSAgaWYgKE5TX1NVQ0NFRURF RChydikpIHsKLSAgICBuc0NBdXRvU3RyaW5nIGxhbmc7Ci0gICAgcnYgPSBzZXJ2aWNlLT5HZXRM YW5ndWFnZShsYW5nKTsKLSAgICBDb3B5QVNDSUl0b1VURjE2KGxhbmcsIGFMYW5ndWFnZSk7Ci0g IH0KLQotICByZXR1cm4gcnY7CisgIC8vIGUuZy4gImRlLWRlLGVuLXVzLCBlbiIKKyAgY29uc3Qg bnNBZG9wdGluZ1N0cmluZyYgYWNjZXB0TGFuZyA9CisgICAgICBuc0NvbnRlbnRVdGlsczo6R2V0 TG9jYWxpemVkU3RyaW5nUHJlZigiaW50bC5hY2NlcHRfbGFuZ3VhZ2VzIik7CisgIC8vIHRha2Ug ZXZlcnl0aGluZyBiZWZvcmUgdGhlIGZpcnN0ICIsIiBvciAiOyIKKyAgbnNDaGFyU2VwYXJhdGVk VG9rZW5pemVyIGxhbmdUb2tlbml6ZXIoYWNjZXB0TGFuZywgJywnKTsKKyAgY29uc3QgbnNTdWJz dHJpbmcgJmZpcnN0TGFuZ1BhcnQgPSBsYW5nVG9rZW5pemVyLm5leHRUb2tlbigpOworICBuc0No YXJTZXBhcmF0ZWRUb2tlbml6ZXIgcVRva2VuaXplcihmaXJzdExhbmdQYXJ0LCAnOycpOworICBh TGFuZ3VhZ2UuQXNzaWduKHFUb2tlbml6ZXIubmV4dFRva2VuKCkpOworICBpZiAoYUxhbmd1YWdl Lkxlbmd0aCgpICE9IDIgJiYgKGFMYW5ndWFnZS5MZW5ndGgoKSAhPSA1IHx8IGFMYW5ndWFnZVsy XSAhPSAnLScpKQorICB7CisgICAgTlNfQVNTRVJUSU9OKGZhbHNlLCAiaW52YWxpZCBpbnRsLmFj Y2VwdF9sYW5ndWFnZXMgcHJlZiIpOworICAgIGFMYW5ndWFnZS5Bc3NpZ24oTlNfTElURVJBTF9T VFJJTkcoImVuIikpOworICB9CisgIHJldHVybiBOU19PSzsKIH0KIAogTlNfSU1FVEhPRElNUAog bnNOYXZpZ2F0b3I6OkdldFBsYXRmb3JtKG5zQVN0cmluZyYgYVBsYXRmb3JtKQogewogICBpZiAo IW5zQ29udGVudFV0aWxzOjpJc0NhbGxlclRydXN0ZWRGb3JSZWFkKCkpIHsKICAgICBjb25zdCBu c0Fkb3B0aW5nQ1N0cmluZyYgb3ZlcnJpZGUgPQogICAgICAgbnNDb250ZW50VXRpbHM6OkdldENo YXJQcmVmKCJnZW5lcmFsLnBsYXRmb3JtLm92ZXJyaWRlIik7Cg== 462244 2010-08-02 16:24:40 -0700 2010-08-03 20:55:45 -0700 Patch 5: Change navigator.language to use Accept-Language lang-js-55366-5.diff text/plain 3901 ben.bucksch ZGlmZiAtLWdpdCBhL2RvbS9iYXNlL25zR2xvYmFsV2luZG93LmNwcCBiL2RvbS9iYXNlL25zR2xv YmFsV2luZG93LmNwcAotLS0gYS9kb20vYmFzZS9uc0dsb2JhbFdpbmRvdy5jcHAKKysrIGIvZG9t L2Jhc2UvbnNHbG9iYWxXaW5kb3cuY3BwCkBAIC0yNSwxNiArMjUsMTcgQEAKICAqICAgQnJlbmRh biBFaWNoIDxicmVuZGFuQG1vemlsbGEub3JnPgogICogICBEYXZpZCBIeWF0dCAoaHlhdHRAbmV0 c2NhcGUuY29tKQogICogICBEYW4gUm9zZW4gPGRyQG5ldHNjYXBlLmNvbT4KICAqICAgVmlkdXIg QXBwYXJhbyA8dmlkdXJAbmV0c2NhcGUuY29tPgogICogICBKb2hubnkgU3RlbmJhY2sgPGpzdEBu ZXRzY2FwZS5jb20+CiAgKiAgIE1hcmsgSGFtbW9uZCA8bWhhbW1vbmRAc2tpcHBpbmV0LmNvbS5h dT4KICAqICAgUnlhbiBKb25lcyA8c2NpZ3V5cnlhbkBnbWFpbC5jb20+CiAgKiAgIEplZmYgV2Fs ZGVuIDxqd2FsZGVuK2NvZGVAbWl0LmVkdT4KKyAqICAgQmVuIEJ1Y2tzY2ggPGJlbi5idWNrc2No ICBiZW9uZXguY29tPgogICoKICAqIEFsdGVybmF0aXZlbHksIHRoZSBjb250ZW50cyBvZiB0aGlz IGZpbGUgbWF5IGJlIHVzZWQgdW5kZXIgdGhlIHRlcm1zIG9mCiAgKiBlaXRoZXIgb2YgdGhlIEdO VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIFZlcnNpb24gMiBvciBsYXRlciAodGhlICJHUEwiKSwK ICAqIG9yIHRoZSBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgVmVyc2lvbiAyLjEg b3IgbGF0ZXIgKHRoZSAiTEdQTCIpLAogICogaW4gd2hpY2ggY2FzZSB0aGUgcHJvdmlzaW9ucyBv ZiB0aGUgR1BMIG9yIHRoZSBMR1BMIGFyZSBhcHBsaWNhYmxlIGluc3RlYWQKICAqIG9mIHRob3Nl IGFib3ZlLiBJZiB5b3Ugd2lzaCB0byBhbGxvdyB1c2Ugb2YgeW91ciB2ZXJzaW9uIG9mIHRoaXMg ZmlsZSBvbmx5CiAgKiB1bmRlciB0aGUgdGVybXMgb2YgZWl0aGVyIHRoZSBHUEwgb3IgdGhlIExH UEwsIGFuZCBub3QgdG8gYWxsb3cgb3RoZXJzIHRvCiAgKiB1c2UgeW91ciB2ZXJzaW9uIG9mIHRo aXMgZmlsZSB1bmRlciB0aGUgdGVybXMgb2YgdGhlIE1QTCwgaW5kaWNhdGUgeW91cgpAQCAtNjIs MTYgKzYzLDE4IEBACiAjaW5jbHVkZSAibnNYUElETFN0cmluZy5oIgogI2luY2x1ZGUgIm5zSlNV dGlscy5oIgogI2luY2x1ZGUgInBybWVtLmgiCiAjaW5jbHVkZSAianNhcGkuaCIgICAgICAgICAg ICAgIC8vIGZvciBKU0F1dG9SZXF1ZXN0CiAjaW5jbHVkZSAianNkYmdhcGkuaCIgICAgICAgICAg IC8vIGZvciBKU19DbGVhcldhdGNoUG9pbnRzRm9yT2JqZWN0CiAjaW5jbHVkZSAibnNSZWFkYWJs ZVV0aWxzLmgiCiAjaW5jbHVkZSAibnNET01DbGFzc0luZm8uaCIKICNpbmNsdWRlICJuc0NvbnRl bnRVdGlscy5oIgorI2luY2x1ZGUgIm5zQ2hhclNlcGFyYXRlZFRva2VuaXplci5oIiAvLyBmb3Ig QWNjZXB0LUxhbmd1YWdlIHBhcnNpbmcKKyNpbmNsdWRlICJuc1VuaWNoYXJVdGlscy5oIgogCiAv LyBPdGhlciBDbGFzc2VzCiAjaW5jbHVkZSAibnNJRXZlbnRMaXN0ZW5lck1hbmFnZXIuaCIKICNp bmNsdWRlICJuc0VzY2FwZS5oIgogI2luY2x1ZGUgIm5zU3R5bGVDb29yZC5oIgogI2luY2x1ZGUg Im5zTWltZVR5cGVBcnJheS5oIgogI2luY2x1ZGUgIm5zTmV0VXRpbC5oIgogI2luY2x1ZGUgIm5z SUNhY2hpbmdDaGFubmVsLmgiCkBAIC05ODU0LDI5ICs5ODU3LDUwIEBAIG5zTmF2aWdhdG9yOjpH ZXRBcHBOYW1lKG5zQVN0cmluZyYgYUFwcE4KICAgICAgIHJldHVybiBOU19PSzsKICAgICB9CiAg IH0KIAogICBhQXBwTmFtZS5Bc3NpZ25MaXRlcmFsKCJOZXRzY2FwZSIpOwogICByZXR1cm4gTlNf T0s7CiB9CiAKKy8qKgorICogSlMgcHJvcGVydHkgbmF2aWdhdG9yLmxhbmd1YWdlLCBleHBvc2Vk IHRvIHdlYiBjb250ZW50LgorICogVGFrZSBmaXJzdCB2YWx1ZSBmcm9tIEFjY2VwdC1MYW5ndWFn ZXMgKEhUVFAgaGVhZGVyKSwgd2hpY2ggaXMKKyAqIHRoZSAiY29udGVudCBsYW5ndWFnZSIgZnJl ZWx5IHNldCBieSB0aGUgdXNlciBpbiB0aGUgUHJlZiB3aW5kb3cuCisgKgorICogRG8gbm90IHVz ZSBVSSBsYW5ndWFnZSAoY2hvc2VuIGFwcCBsb2NhbGUpIGhlcmUuCisgKiBTZWUgUkZDIDI2MTYs IFNlY3Rpb24gMTUuMS40ICJQcml2YWN5IElzc3VlcyBDb25uZWN0ZWQgdG8gQWNjZXB0IEhlYWRl cnMiCisgKgorICogImVuIiwgImVuLVVTIiBhbmQgImktY2hlcm9rZWUiIGFyZSB2YWxpZC4KKyAq IEZhbGxiYWNrIGluIGNhc2Ugb2YgaW52YWxpZCBwcmVmIHNob3VsZCBiZSAiIiAoZW1wdHkgc3Ry aW5nKSwgdG8KKyAqIGxldCBzaXRlIGRvIGZhbGxiYWNrLCBlLmcuIHRvIHNpdGUncyBsb2NhbCBs YW5ndWFnZS4KKyAqLwogTlNfSU1FVEhPRElNUAogbnNOYXZpZ2F0b3I6OkdldExhbmd1YWdlKG5z QVN0cmluZyYgYUxhbmd1YWdlKQogewotICBuc3Jlc3VsdCBydjsKLSAgbnNDT01QdHI8bnNJSHR0 cFByb3RvY29sSGFuZGxlcj4KLSAgICBzZXJ2aWNlKGRvX0dldFNlcnZpY2UoTlNfTkVUV09SS19Q Uk9UT0NPTF9DT05UUkFDVElEX1BSRUZJWCAiaHR0cCIsICZydikpOwotICBpZiAoTlNfU1VDQ0VF REVEKHJ2KSkgewotICAgIG5zQ0F1dG9TdHJpbmcgbGFuZzsKLSAgICBydiA9IHNlcnZpY2UtPkdl dExhbmd1YWdlKGxhbmcpOwotICAgIENvcHlBU0NJSXRvVVRGMTYobGFuZywgYUxhbmd1YWdlKTsK LSAgfQotCi0gIHJldHVybiBydjsKKyAgLy8gZS5nLiAiZGUtZGUsIGVuLXVzLGVuIgorICBjb25z dCBuc0Fkb3B0aW5nU3RyaW5nJiBhY2NlcHRMYW5nID0KKyAgICAgIG5zQ29udGVudFV0aWxzOjpH ZXRMb2NhbGl6ZWRTdHJpbmdQcmVmKCJpbnRsLmFjY2VwdF9sYW5ndWFnZXMiKTsKKyAgLy8gdGFr ZSBldmVyeXRoaW5nIGJlZm9yZSB0aGUgZmlyc3QgIiwiIG9yICI7Iiwgd2l0aG91dCB0cmFpbGlu ZyBzcGFjZQorICBuc0NoYXJTZXBhcmF0ZWRUb2tlbml6ZXIgbGFuZ1Rva2VuaXplcihhY2NlcHRM YW5nLCAnLCcpOworICBjb25zdCBuc1N1YnN0cmluZyAmZmlyc3RMYW5nUGFydCA9IGxhbmdUb2tl bml6ZXIubmV4dFRva2VuKCk7CisgIG5zQ2hhclNlcGFyYXRlZFRva2VuaXplciBxVG9rZW5pemVy KGZpcnN0TGFuZ1BhcnQsICc7Jyk7CisgIGFMYW5ndWFnZS5Bc3NpZ24ocVRva2VuaXplci5uZXh0 VG9rZW4oKSk7CisgIE5TX0FTU0VSVElPTighYUxhbmd1YWdlLklzRW1wdHkoKSwgImludmFsaWQg aW50bC5hY2NlcHRfbGFuZ3VhZ2VzIHByZWYiKTsKKyAgLy8gcmVwbGFjZSAiXyIgd2l0aCAiLSIs IHRvIGF2b2lkIFBPU0lYL1dpbmRvd3MgImVuX1VTIiBub3RhdGlvbgorICBpZiAoYUxhbmd1YWdl Lkxlbmd0aCgpID4gMiAmJiBhTGFuZ3VhZ2VbMl0gPT0gUFJVbmljaGFyKCdfJykpCisgICAgYUxh bmd1YWdlLlJlcGxhY2UoMiwgMSwgUFJVbmljaGFyKCctJykpOyAvLyBUT0RPIHJlcGxhY2UgYWxs CisgIGlmIChhTGFuZ3VhZ2UuTGVuZ3RoKCkgPiAyICYmIGFMYW5ndWFnZVsyXSA9PSBQUlVuaWNo YXIoJy0nKSkKKyAgeworICAgIG5zQXV0b1N0cmluZyB1cHBlcihTdWJzdHJpbmcoYUxhbmd1YWdl LCAzLCBhTGFuZ3VhZ2UuTGVuZ3RoKCkgLSAzKSk7CisgICAgOjpUb1VwcGVyQ2FzZSh1cHBlcik7 CisgICAgYUxhbmd1YWdlLlJlcGxhY2UoMywgYUxhbmd1YWdlLkxlbmd0aCgpIC0gMywgdXBwZXIp OworICB9CisgIHJldHVybiBOU19PSzsKIH0KIAogTlNfSU1FVEhPRElNUAogbnNOYXZpZ2F0b3I6 OkdldFBsYXRmb3JtKG5zQVN0cmluZyYgYVBsYXRmb3JtKQogewogICBpZiAoIW5zQ29udGVudFV0 aWxzOjpJc0NhbGxlclRydXN0ZWRGb3JSZWFkKCkpIHsKICAgICBjb25zdCBuc0Fkb3B0aW5nQ1N0 cmluZyYgb3ZlcnJpZGUgPQogICAgICAgbnNDb250ZW50VXRpbHM6OkdldENoYXJQcmVmKCJnZW5l cmFsLnBsYXRmb3JtLm92ZXJyaWRlIik7Cg== 462638 2010-08-03 19:52:14 -0700 2010-08-03 21:03:01 -0700 Patch 6: Change navigator.language to use Accept-Language, using tokerizer for uppercasing lang-js-55366-6.diff text/plain 4325 ben.bucksch ZGlmZiAtLWdpdCBhL2RvbS9iYXNlL25zR2xvYmFsV2luZG93LmNwcCBiL2RvbS9iYXNlL25zR2xv YmFsV2luZG93LmNwcAotLS0gYS9kb20vYmFzZS9uc0dsb2JhbFdpbmRvdy5jcHAKKysrIGIvZG9t L2Jhc2UvbnNHbG9iYWxXaW5kb3cuY3BwCkBAIC0yNSwxNiArMjUsMTcgQEAKICAqICAgQnJlbmRh biBFaWNoIDxicmVuZGFuQG1vemlsbGEub3JnPgogICogICBEYXZpZCBIeWF0dCAoaHlhdHRAbmV0 c2NhcGUuY29tKQogICogICBEYW4gUm9zZW4gPGRyQG5ldHNjYXBlLmNvbT4KICAqICAgVmlkdXIg QXBwYXJhbyA8dmlkdXJAbmV0c2NhcGUuY29tPgogICogICBKb2hubnkgU3RlbmJhY2sgPGpzdEBu ZXRzY2FwZS5jb20+CiAgKiAgIE1hcmsgSGFtbW9uZCA8bWhhbW1vbmRAc2tpcHBpbmV0LmNvbS5h dT4KICAqICAgUnlhbiBKb25lcyA8c2NpZ3V5cnlhbkBnbWFpbC5jb20+CiAgKiAgIEplZmYgV2Fs ZGVuIDxqd2FsZGVuK2NvZGVAbWl0LmVkdT4KKyAqICAgQmVuIEJ1Y2tzY2ggPGJlbi5idWNrc2No ICBiZW9uZXguY29tPgogICoKICAqIEFsdGVybmF0aXZlbHksIHRoZSBjb250ZW50cyBvZiB0aGlz IGZpbGUgbWF5IGJlIHVzZWQgdW5kZXIgdGhlIHRlcm1zIG9mCiAgKiBlaXRoZXIgb2YgdGhlIEdO VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIFZlcnNpb24gMiBvciBsYXRlciAodGhlICJHUEwiKSwK ICAqIG9yIHRoZSBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgVmVyc2lvbiAyLjEg b3IgbGF0ZXIgKHRoZSAiTEdQTCIpLAogICogaW4gd2hpY2ggY2FzZSB0aGUgcHJvdmlzaW9ucyBv ZiB0aGUgR1BMIG9yIHRoZSBMR1BMIGFyZSBhcHBsaWNhYmxlIGluc3RlYWQKICAqIG9mIHRob3Nl IGFib3ZlLiBJZiB5b3Ugd2lzaCB0byBhbGxvdyB1c2Ugb2YgeW91ciB2ZXJzaW9uIG9mIHRoaXMg ZmlsZSBvbmx5CiAgKiB1bmRlciB0aGUgdGVybXMgb2YgZWl0aGVyIHRoZSBHUEwgb3IgdGhlIExH UEwsIGFuZCBub3QgdG8gYWxsb3cgb3RoZXJzIHRvCiAgKiB1c2UgeW91ciB2ZXJzaW9uIG9mIHRo aXMgZmlsZSB1bmRlciB0aGUgdGVybXMgb2YgdGhlIE1QTCwgaW5kaWNhdGUgeW91cgpAQCAtNjIs MTYgKzYzLDE4IEBACiAjaW5jbHVkZSAibnNYUElETFN0cmluZy5oIgogI2luY2x1ZGUgIm5zSlNV dGlscy5oIgogI2luY2x1ZGUgInBybWVtLmgiCiAjaW5jbHVkZSAianNhcGkuaCIgICAgICAgICAg ICAgIC8vIGZvciBKU0F1dG9SZXF1ZXN0CiAjaW5jbHVkZSAianNkYmdhcGkuaCIgICAgICAgICAg IC8vIGZvciBKU19DbGVhcldhdGNoUG9pbnRzRm9yT2JqZWN0CiAjaW5jbHVkZSAibnNSZWFkYWJs ZVV0aWxzLmgiCiAjaW5jbHVkZSAibnNET01DbGFzc0luZm8uaCIKICNpbmNsdWRlICJuc0NvbnRl bnRVdGlscy5oIgorI2luY2x1ZGUgIm5zQ2hhclNlcGFyYXRlZFRva2VuaXplci5oIiAvLyBmb3Ig QWNjZXB0LUxhbmd1YWdlIHBhcnNpbmcKKyNpbmNsdWRlICJuc1VuaWNoYXJVdGlscy5oIgogCiAv LyBPdGhlciBDbGFzc2VzCiAjaW5jbHVkZSAibnNJRXZlbnRMaXN0ZW5lck1hbmFnZXIuaCIKICNp bmNsdWRlICJuc0VzY2FwZS5oIgogI2luY2x1ZGUgIm5zU3R5bGVDb29yZC5oIgogI2luY2x1ZGUg Im5zTWltZVR5cGVBcnJheS5oIgogI2luY2x1ZGUgIm5zTmV0VXRpbC5oIgogI2luY2x1ZGUgIm5z SUNhY2hpbmdDaGFubmVsLmgiCkBAIC05ODU0LDI5ICs5ODU3LDY2IEBAIG5zTmF2aWdhdG9yOjpH ZXRBcHBOYW1lKG5zQVN0cmluZyYgYUFwcE4KICAgICAgIHJldHVybiBOU19PSzsKICAgICB9CiAg IH0KIAogICBhQXBwTmFtZS5Bc3NpZ25MaXRlcmFsKCJOZXRzY2FwZSIpOwogICByZXR1cm4gTlNf T0s7CiB9CiAKKy8qKgorICogSlMgcHJvcGVydHkgbmF2aWdhdG9yLmxhbmd1YWdlLCBleHBvc2Vk IHRvIHdlYiBjb250ZW50LgorICogVGFrZSBmaXJzdCB2YWx1ZSBmcm9tIEFjY2VwdC1MYW5ndWFn ZXMgKEhUVFAgaGVhZGVyKSwgd2hpY2ggaXMKKyAqIHRoZSAiY29udGVudCBsYW5ndWFnZSIgZnJl ZWx5IHNldCBieSB0aGUgdXNlciBpbiB0aGUgUHJlZiB3aW5kb3cuCisgKgorICogRG8gbm90IHVz ZSBVSSBsYW5ndWFnZSAoY2hvc2VuIGFwcCBsb2NhbGUpIGhlcmUuCisgKiBTZWUgUkZDIDI2MTYs IFNlY3Rpb24gMTUuMS40ICJQcml2YWN5IElzc3VlcyBDb25uZWN0ZWQgdG8gQWNjZXB0IEhlYWRl cnMiCisgKgorICogImVuIiwgImVuLVVTIiBhbmQgImktY2hlcm9rZWUiIGFuZCAiIiBhcmUgdmFs aWQuCisgKiBGYWxsYmFjayBpbiBjYXNlIG9mIGludmFsaWQgcHJlZiBzaG91bGQgYmUgIiIgKGVt cHR5IHN0cmluZyksIHRvCisgKiBsZXQgc2l0ZSBkbyBmYWxsYmFjaywgZS5nLiB0byBzaXRlJ3Mg bG9jYWwgbGFuZ3VhZ2UuCisgKi8KIE5TX0lNRVRIT0RJTVAKIG5zTmF2aWdhdG9yOjpHZXRMYW5n dWFnZShuc0FTdHJpbmcmIGFMYW5ndWFnZSkKIHsKLSAgbnNyZXN1bHQgcnY7Ci0gIG5zQ09NUHRy PG5zSUh0dHBQcm90b2NvbEhhbmRsZXI+Ci0gICAgc2VydmljZShkb19HZXRTZXJ2aWNlKE5TX05F VFdPUktfUFJPVE9DT0xfQ09OVFJBQ1RJRF9QUkVGSVggImh0dHAiLCAmcnYpKTsKLSAgaWYgKE5T X1NVQ0NFRURFRChydikpIHsKLSAgICBuc0NBdXRvU3RyaW5nIGxhbmc7Ci0gICAgcnYgPSBzZXJ2 aWNlLT5HZXRMYW5ndWFnZShsYW5nKTsKLSAgICBDb3B5QVNDSUl0b1VURjE2KGxhbmcsIGFMYW5n dWFnZSk7Ci0gIH0KLQotICByZXR1cm4gcnY7CisgIC8vIGUuZy4gImRlLWRlLCBlbi11cyxlbiIK KyAgY29uc3QgbnNBZG9wdGluZ1N0cmluZyYgYWNjZXB0TGFuZyA9CisgICAgICBuc0NvbnRlbnRV dGlsczo6R2V0TG9jYWxpemVkU3RyaW5nUHJlZigiaW50bC5hY2NlcHRfbGFuZ3VhZ2VzIik7Cisg IC8vIHRha2UgZXZlcnl0aGluZyBiZWZvcmUgdGhlIGZpcnN0ICIsIiBvciAiOyIsIHdpdGhvdXQg dHJhaWxpbmcgc3BhY2UKKyAgbnNDaGFyU2VwYXJhdGVkVG9rZW5pemVyIGxhbmdUb2tlbml6ZXIo YWNjZXB0TGFuZywgJywnKTsKKyAgY29uc3QgbnNTdWJzdHJpbmcgJmZpcnN0TGFuZ1BhcnQgPSBs YW5nVG9rZW5pemVyLm5leHRUb2tlbigpOworICBuc0NoYXJTZXBhcmF0ZWRUb2tlbml6ZXIgcVRv a2VuaXplcihmaXJzdExhbmdQYXJ0LCAnOycpOworICBhTGFuZ3VhZ2UuQXNzaWduKHFUb2tlbml6 ZXIubmV4dFRva2VuKCkpOworCisgIC8vIGNoZWNrcyBhbmQgZml4dXBzCisgIC8vIHJlcGxhY2Ug Il8iIHdpdGggIi0iLCB0byBhdm9pZCBQT1NJWC9XaW5kb3dzICJlbl9VUyIgbm90YXRpb24KKyAg aWYgKGFMYW5ndWFnZS5MZW5ndGgoKSA+IDIgJiYgYUxhbmd1YWdlWzJdID09IFBSVW5pY2hhcign XycpKQorICAgIGFMYW5ndWFnZS5SZXBsYWNlKDIsIDEsIFBSVW5pY2hhcignLScpKTsgLy8gVE9E TyByZXBsYWNlIGFsbAorICAvLyB1c2UgdXBwZXJjYXNlIGZvciBjb3VudHJ5IHBhcnQsIGUuZy4g ImVuLVVTIiwgbm90ICJlbi11cyIsIHNlZSBCQ1A0NworICAvLyBvbmx5IHVwcGVyY2FzZSAyLWxl dHRlciBjb3VudHJ5IGNvZGVzLCBub3QgInpoLUhhbnQiLCAiZGUtREUteC1nb2V0aGUiCisgIGlm IChhTGFuZ3VhZ2UuTGVuZ3RoKCkgPiAyKQorICB7CisgICAgbnNDaGFyU2VwYXJhdGVkVG9rZW5p emVyIGxvY2FsZVRva2VuaXplcihhTGFuZ3VhZ2UsICctJyk7CisgICAgUFJJbnQzMiBwb3MgPSAw OworICAgIFBSQm9vbCBmaXJzdCA9IHRydWU7CisgICAgd2hpbGUgKGxvY2FsZVRva2VuaXplci5o YXNNb3JlVG9rZW5zKCkpCisgICAgeworICAgICAgY29uc3QgbnNTdWJzdHJpbmcgJmNvZGUgPSBs b2NhbGVUb2tlbml6ZXIubmV4dFRva2VuKCk7CisgICAgICBpZiAoY29kZS5MZW5ndGgoKSA9PSAy ICYmICFmaXJzdCkKKyAgICAgIHsKKyAgICAgICAgbnNBdXRvU3RyaW5nIHVwcGVyKGNvZGUpOwor ICAgICAgICA6OlRvVXBwZXJDYXNlKHVwcGVyKTsKKyAgICAgICAgYUxhbmd1YWdlLlJlcGxhY2Uo cG9zLCBjb2RlLkxlbmd0aCgpLCB1cHBlcik7CisgICAgICB9CisgICAgICBwb3MgKz0gY29kZS5M ZW5ndGgoKSArIDE7IC8vIDEgaXMgdGhlIHNlcGFyYXRvcgorICAgICAgaWYgKGZpcnN0KQorICAg ICAgICBmaXJzdCA9IGZhbHNlOworICAgIH0KKyAgfQorICByZXR1cm4gTlNfT0s7CiB9CiAKIE5T X0lNRVRIT0RJTVAKIG5zTmF2aWdhdG9yOjpHZXRQbGF0Zm9ybShuc0FTdHJpbmcmIGFQbGF0Zm9y bSkKIHsKICAgaWYgKCFuc0NvbnRlbnRVdGlsczo6SXNDYWxsZXJUcnVzdGVkRm9yUmVhZCgpKSB7 CiAgICAgY29uc3QgbnNBZG9wdGluZ0NTdHJpbmcmIG92ZXJyaWRlID0KICAgICAgIG5zQ29udGVu dFV0aWxzOjpHZXRDaGFyUHJlZigiZ2VuZXJhbC5wbGF0Zm9ybS5vdmVycmlkZSIpOwo= 462663 2010-08-03 21:03:01 -0700 2010-10-29 14:06:42 -0700 Patch 7: Change navigator.language to use Accept-Language lang-js-55366-7.diff text/plain 4323 ben.bucksch ZGlmZiAtLWdpdCBhL2RvbS9iYXNlL25zR2xvYmFsV2luZG93LmNwcCBiL2RvbS9iYXNlL25zR2xv YmFsV2luZG93LmNwcAotLS0gYS9kb20vYmFzZS9uc0dsb2JhbFdpbmRvdy5jcHAKKysrIGIvZG9t L2Jhc2UvbnNHbG9iYWxXaW5kb3cuY3BwCkBAIC0yNSwxNiArMjUsMTcgQEAKICAqICAgQnJlbmRh biBFaWNoIDxicmVuZGFuQG1vemlsbGEub3JnPgogICogICBEYXZpZCBIeWF0dCAoaHlhdHRAbmV0 c2NhcGUuY29tKQogICogICBEYW4gUm9zZW4gPGRyQG5ldHNjYXBlLmNvbT4KICAqICAgVmlkdXIg QXBwYXJhbyA8dmlkdXJAbmV0c2NhcGUuY29tPgogICogICBKb2hubnkgU3RlbmJhY2sgPGpzdEBu ZXRzY2FwZS5jb20+CiAgKiAgIE1hcmsgSGFtbW9uZCA8bWhhbW1vbmRAc2tpcHBpbmV0LmNvbS5h dT4KICAqICAgUnlhbiBKb25lcyA8c2NpZ3V5cnlhbkBnbWFpbC5jb20+CiAgKiAgIEplZmYgV2Fs ZGVuIDxqd2FsZGVuK2NvZGVAbWl0LmVkdT4KKyAqICAgQmVuIEJ1Y2tzY2ggPGJlbi5idWNrc2No ICBiZW9uZXguY29tPgogICoKICAqIEFsdGVybmF0aXZlbHksIHRoZSBjb250ZW50cyBvZiB0aGlz IGZpbGUgbWF5IGJlIHVzZWQgdW5kZXIgdGhlIHRlcm1zIG9mCiAgKiBlaXRoZXIgb2YgdGhlIEdO VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIFZlcnNpb24gMiBvciBsYXRlciAodGhlICJHUEwiKSwK ICAqIG9yIHRoZSBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgVmVyc2lvbiAyLjEg b3IgbGF0ZXIgKHRoZSAiTEdQTCIpLAogICogaW4gd2hpY2ggY2FzZSB0aGUgcHJvdmlzaW9ucyBv ZiB0aGUgR1BMIG9yIHRoZSBMR1BMIGFyZSBhcHBsaWNhYmxlIGluc3RlYWQKICAqIG9mIHRob3Nl IGFib3ZlLiBJZiB5b3Ugd2lzaCB0byBhbGxvdyB1c2Ugb2YgeW91ciB2ZXJzaW9uIG9mIHRoaXMg ZmlsZSBvbmx5CiAgKiB1bmRlciB0aGUgdGVybXMgb2YgZWl0aGVyIHRoZSBHUEwgb3IgdGhlIExH UEwsIGFuZCBub3QgdG8gYWxsb3cgb3RoZXJzIHRvCiAgKiB1c2UgeW91ciB2ZXJzaW9uIG9mIHRo aXMgZmlsZSB1bmRlciB0aGUgdGVybXMgb2YgdGhlIE1QTCwgaW5kaWNhdGUgeW91cgpAQCAtNjIs MTYgKzYzLDE4IEBACiAjaW5jbHVkZSAibnNYUElETFN0cmluZy5oIgogI2luY2x1ZGUgIm5zSlNV dGlscy5oIgogI2luY2x1ZGUgInBybWVtLmgiCiAjaW5jbHVkZSAianNhcGkuaCIgICAgICAgICAg ICAgIC8vIGZvciBKU0F1dG9SZXF1ZXN0CiAjaW5jbHVkZSAianNkYmdhcGkuaCIgICAgICAgICAg IC8vIGZvciBKU19DbGVhcldhdGNoUG9pbnRzRm9yT2JqZWN0CiAjaW5jbHVkZSAibnNSZWFkYWJs ZVV0aWxzLmgiCiAjaW5jbHVkZSAibnNET01DbGFzc0luZm8uaCIKICNpbmNsdWRlICJuc0NvbnRl bnRVdGlscy5oIgorI2luY2x1ZGUgIm5zQ2hhclNlcGFyYXRlZFRva2VuaXplci5oIiAvLyBmb3Ig QWNjZXB0LUxhbmd1YWdlIHBhcnNpbmcKKyNpbmNsdWRlICJuc1VuaWNoYXJVdGlscy5oIgogCiAv LyBPdGhlciBDbGFzc2VzCiAjaW5jbHVkZSAibnNJRXZlbnRMaXN0ZW5lck1hbmFnZXIuaCIKICNp bmNsdWRlICJuc0VzY2FwZS5oIgogI2luY2x1ZGUgIm5zU3R5bGVDb29yZC5oIgogI2luY2x1ZGUg Im5zTWltZVR5cGVBcnJheS5oIgogI2luY2x1ZGUgIm5zTmV0VXRpbC5oIgogI2luY2x1ZGUgIm5z SUNhY2hpbmdDaGFubmVsLmgiCkBAIC05ODU0LDI5ICs5ODU3LDY2IEBAIG5zTmF2aWdhdG9yOjpH ZXRBcHBOYW1lKG5zQVN0cmluZyYgYUFwcE4KICAgICAgIHJldHVybiBOU19PSzsKICAgICB9CiAg IH0KIAogICBhQXBwTmFtZS5Bc3NpZ25MaXRlcmFsKCJOZXRzY2FwZSIpOwogICByZXR1cm4gTlNf T0s7CiB9CiAKKy8qKgorICogSlMgcHJvcGVydHkgbmF2aWdhdG9yLmxhbmd1YWdlLCBleHBvc2Vk IHRvIHdlYiBjb250ZW50LgorICogVGFrZSBmaXJzdCB2YWx1ZSBmcm9tIEFjY2VwdC1MYW5ndWFn ZXMgKEhUVFAgaGVhZGVyKSwgd2hpY2ggaXMKKyAqIHRoZSAiY29udGVudCBsYW5ndWFnZSIgZnJl ZWx5IHNldCBieSB0aGUgdXNlciBpbiB0aGUgUHJlZiB3aW5kb3cuCisgKgorICogRG8gbm90IHVz ZSBVSSBsYW5ndWFnZSAoY2hvc2VuIGFwcCBsb2NhbGUpIGhlcmUuCisgKiBTZWUgUkZDIDI2MTYs IFNlY3Rpb24gMTUuMS40ICJQcml2YWN5IElzc3VlcyBDb25uZWN0ZWQgdG8gQWNjZXB0IEhlYWRl cnMiCisgKgorICogImVuIiwgImVuLVVTIiBhbmQgImktY2hlcm9rZWUiIGFuZCAiIiBhcmUgdmFs aWQuCisgKiBGYWxsYmFjayBpbiBjYXNlIG9mIGludmFsaWQgcHJlZiBzaG91bGQgYmUgIiIgKGVt cHR5IHN0cmluZyksIHRvCisgKiBsZXQgc2l0ZSBkbyBmYWxsYmFjaywgZS5nLiB0byBzaXRlJ3Mg bG9jYWwgbGFuZ3VhZ2UuCisgKi8KIE5TX0lNRVRIT0RJTVAKIG5zTmF2aWdhdG9yOjpHZXRMYW5n dWFnZShuc0FTdHJpbmcmIGFMYW5ndWFnZSkKIHsKLSAgbnNyZXN1bHQgcnY7Ci0gIG5zQ09NUHRy PG5zSUh0dHBQcm90b2NvbEhhbmRsZXI+Ci0gICAgc2VydmljZShkb19HZXRTZXJ2aWNlKE5TX05F VFdPUktfUFJPVE9DT0xfQ09OVFJBQ1RJRF9QUkVGSVggImh0dHAiLCAmcnYpKTsKLSAgaWYgKE5T X1NVQ0NFRURFRChydikpIHsKLSAgICBuc0NBdXRvU3RyaW5nIGxhbmc7Ci0gICAgcnYgPSBzZXJ2 aWNlLT5HZXRMYW5ndWFnZShsYW5nKTsKLSAgICBDb3B5QVNDSUl0b1VURjE2KGxhbmcsIGFMYW5n dWFnZSk7Ci0gIH0KLQotICByZXR1cm4gcnY7CisgIC8vIGUuZy4gImRlLWRlLCBlbi11cyxlbiIK KyAgY29uc3QgbnNBZG9wdGluZ1N0cmluZyYgYWNjZXB0TGFuZyA9CisgICAgICBuc0NvbnRlbnRV dGlsczo6R2V0TG9jYWxpemVkU3RyaW5nUHJlZigiaW50bC5hY2NlcHRfbGFuZ3VhZ2VzIik7Cisg IC8vIHRha2UgZXZlcnl0aGluZyBiZWZvcmUgdGhlIGZpcnN0ICIsIiBvciAiOyIsIHdpdGhvdXQg dHJhaWxpbmcgc3BhY2UKKyAgbnNDaGFyU2VwYXJhdGVkVG9rZW5pemVyIGxhbmdUb2tlbml6ZXIo YWNjZXB0TGFuZywgJywnKTsKKyAgY29uc3QgbnNTdWJzdHJpbmcgJmZpcnN0TGFuZ1BhcnQgPSBs YW5nVG9rZW5pemVyLm5leHRUb2tlbigpOworICBuc0NoYXJTZXBhcmF0ZWRUb2tlbml6ZXIgcVRv a2VuaXplcihmaXJzdExhbmdQYXJ0LCAnOycpOworICBhTGFuZ3VhZ2UuQXNzaWduKHFUb2tlbml6 ZXIubmV4dFRva2VuKCkpOworCisgIC8vIGNoZWNrcyBhbmQgZml4dXBzCisgIC8vIHJlcGxhY2Ug Il8iIHdpdGggIi0iLCB0byBhdm9pZCBQT1NJWC9XaW5kb3dzICJlbl9VUyIgbm90YXRpb24KKyAg aWYgKGFMYW5ndWFnZS5MZW5ndGgoKSA+IDIgJiYgYUxhbmd1YWdlWzJdID09IFBSVW5pY2hhcign XycpKQorICAgIGFMYW5ndWFnZS5SZXBsYWNlKDIsIDEsIFBSVW5pY2hhcignLScpKTsgLy8gVE9E TyByZXBsYWNlIGFsbAorICAvLyB1c2UgdXBwZXJjYXNlIGZvciBjb3VudHJ5IHBhcnQsIGUuZy4g ImVuLVVTIiwgbm90ICJlbi11cyIsIHNlZSBCQ1A0NworICAvLyBvbmx5IHVwcGVyY2FzZSAyLWxl dHRlciBjb3VudHJ5IGNvZGVzLCBub3QgInpoLUhhbnQiLCAiZGUtREUteC1nb2V0aGUiCisgIGlm IChhTGFuZ3VhZ2UuTGVuZ3RoKCkgPiAyKQorICB7CisgICAgbnNDaGFyU2VwYXJhdGVkVG9rZW5p emVyIGxvY2FsZVRva2VuaXplcihhTGFuZ3VhZ2UsICctJyk7CisgICAgUFJJbnQzMiBwb3MgPSAw OworICAgIGJvb2wgZmlyc3QgPSB0cnVlOworICAgIHdoaWxlIChsb2NhbGVUb2tlbml6ZXIuaGFz TW9yZVRva2VucygpKQorICAgIHsKKyAgICAgIGNvbnN0IG5zU3Vic3RyaW5nICZjb2RlID0gbG9j YWxlVG9rZW5pemVyLm5leHRUb2tlbigpOworICAgICAgaWYgKGNvZGUuTGVuZ3RoKCkgPT0gMiAm JiAhZmlyc3QpCisgICAgICB7CisgICAgICAgIG5zQXV0b1N0cmluZyB1cHBlcihjb2RlKTsKKyAg ICAgICAgOjpUb1VwcGVyQ2FzZSh1cHBlcik7CisgICAgICAgIGFMYW5ndWFnZS5SZXBsYWNlKHBv cywgY29kZS5MZW5ndGgoKSwgdXBwZXIpOworICAgICAgfQorICAgICAgcG9zICs9IGNvZGUuTGVu Z3RoKCkgKyAxOyAvLyAxIGlzIHRoZSBzZXBhcmF0b3IKKyAgICAgIGlmIChmaXJzdCkKKyAgICAg ICAgZmlyc3QgPSBmYWxzZTsKKyAgICB9CisgIH0KKyAgcmV0dXJuIE5TX09LOwogfQogCiBOU19J TUVUSE9ESU1QCiBuc05hdmlnYXRvcjo6R2V0UGxhdGZvcm0obnNBU3RyaW5nJiBhUGxhdGZvcm0p CiB7CiAgIGlmICghbnNDb250ZW50VXRpbHM6OklzQ2FsbGVyVHJ1c3RlZEZvclJlYWQoKSkgewog ICAgIGNvbnN0IG5zQWRvcHRpbmdDU3RyaW5nJiBvdmVycmlkZSA9CiAgICAgICBuc0NvbnRlbnRV dGlsczo6R2V0Q2hhclByZWYoImdlbmVyYWwucGxhdGZvcm0ub3ZlcnJpZGUiKTsK