5013bff6e5bf3dbe75c3c00416df54dd94c66607: Bug 1400006 - Extend language negotiation in LocaleService to support looking for the best likelySubtag for the locale with region stripped. r?jfkthame draft
Zibi Braniecki <zbraniecki@mozilla.com> - Thu, 14 Sep 2017 15:21:33 -0700 - rev 666410
Push 80399 by bwerth@mozilla.com at Mon, 18 Sep 2017 18:17:11 +0000
Bug 1400006 - Extend language negotiation in LocaleService to support looking for the best likelySubtag for the locale with region stripped. r?jfkthame This fixes a limitation of our current language negotiation algorithm that affects our users. If the user specifies the locale with region, and we do not have a direct for that region, we currently pick all locales for the same language and other regions in no order. The example of where it returns suboptimal results: 1) Requested locale "en-CA" 2) Available locales ["en-ZA", "en-GB", "en-US"] 3) Negotiated locales ["en-ZA", "en-GB", "en-US"] This would not happen, if the user requested a generic "de", "en" etc.: 1) Requested locale "en" 2) Available locales ["en-ZA", "en-GB", "en-US"] 3) Negotiated locales ["en-US", "en-ZA", "en-GB"] because after not finding a direct match, we would use likelySubtags to extend "en" to "en-Latn-US" and then find the priority match in "en-US". This patch extends this logic to "en-US" or "de-LU" by adding a step which strips the region tag and then applies likelySubtag on the result. This means that in absence of direct match the following fallbacks would happen: "de-LU" -> "de-DE" "es-CL" -> "es-ES" "en-CA" -> "en-US" This does not affect languages that use multiple scripts, so ar, sr and zh are not affected. MozReview-Commit-ID: BR1WrgXSf6a
79cc2d6bdc756c778dc1a52e445132e409ba9371: Bug 1387557 - Transition to fatter progressbar. r=mikedeboer draft
Sam Foster <sfoster@mozilla.com> - Tue, 12 Sep 2017 00:08:43 -0700 - rev 666409
Push 80398 by bmo:sfoster@mozilla.com at Mon, 18 Sep 2017 18:16:59 +0000
Bug 1387557 - Transition to fatter progressbar. r=mikedeboer * Pre-rendered animations to transition to the fatter progressbar * Frames of the indicator graphic in the notifier replace and overlay the button indicator, so that we can control the ease-in of the progressbar and transition of the arrow from an attention state * Forward selected attributes to the notifier element to drive animation behavior & specifics * Transition from not-downloading to downloading state in the notifier, revealing the indicator when the animation complete * Animate the transition from attention=success to none with a pre-rendered svg animation MozReview-Commit-ID: BDguf62lTyt
065b0491289b4303d355b7600f9bdbc5e71a0a97: Bug 1395890 - Change all ESLint rules that are warnings to errors. r?standard8 draft
Dan Banner <dbugs@thebanners.uk> - Mon, 18 Sep 2017 19:07:17 +0100 - rev 666408
Push 80397 by bmo:dbugs@thebanners.uk at Mon, 18 Sep 2017 18:14:32 +0000
Bug 1395890 - Change all ESLint rules that are warnings to errors. r?standard8 MozReview-Commit-ID: LJS6m1GppiS
be0bea272d5a2b6d2a1a2462555bdc03a97ea328: bug 1400913 - back out the functionality changes from bug 1364159 (but keep the test) r?jcj draft
David Keeler <dkeeler@mozilla.com> - Mon, 18 Sep 2017 10:28:58 -0700 - rev 666407
Push 80396 by bmo:dkeeler@mozilla.com at Mon, 18 Sep 2017 18:13:27 +0000
bug 1400913 - back out the functionality changes from bug 1364159 (but keep the test) r?jcj Bug 1364159 introduced an optimization that attempted to avoid reading from the user's cached certificate database as much as possible when building a verified certificate chain. Unfortunately this had the side-effect of not preferring root certificates in path building, which can result in unnecessarily long chains (which rather defeats the purpose, since it means more signature verifications). This patch reverts the functionality changes from that bug but keeps the test that was added (the test didn't directly test the functionality changes - it's more of a check that path building will query the cached certificate db when necessary). MozReview-Commit-ID: I56THTLUytH
eab323a9ae2dc9322014f62df98b8fb90fa96992: Bug 1400006 - Extend language negotiation in LocaleService to support looking for the best likelySubtag for the locale with region stripped. r?jfkthame draft
Zibi Braniecki <zbraniecki@mozilla.com> - Thu, 14 Sep 2017 15:21:33 -0700 - rev 666406
Push 80395 by bwerth@mozilla.com at Mon, 18 Sep 2017 18:11:41 +0000
Bug 1400006 - Extend language negotiation in LocaleService to support looking for the best likelySubtag for the locale with region stripped. r?jfkthame This fixes a limitation of our current language negotiation algorithm that affects our users. If the user specifies the locale with region, and we do not have a direct for that region, we currently pick all locales for the same language and other regions in no order. The example of where it returns suboptimal results: 1) Requested locale "en-CA" 2) Available locales ["en-ZA", "en-GB", "en-US"] 3) Negotiated locales ["en-ZA", "en-GB", "en-US"] This would not happen, if the user requested a generic "de", "en" etc.: 1) Requested locale "en" 2) Available locales ["en-ZA", "en-GB", "en-US"] 3) Negotiated locales ["en-US", "en-ZA", "en-GB"] because after not finding a direct match, we would use likelySubtags to extend "en" to "en-Latn-US" and then find the priority match in "en-US". This patch extends this logic to "en-US" or "de-LU" by adding a step which strips the region tag and then applies likelySubtag on the result. This means that in absence of direct match the following fallbacks would happen: "de-LU" -> "de-DE" "es-CL" -> "es-ES" "en-CA" -> "en-US" This does not affect languages that use multiple scripts, so ar, sr and zh are not affected. MozReview-Commit-ID: BR1WrgXSf6a
9a4b7a9249d7924b091d3b233d35084b9cad41f8: Bug 1388789 - clean up \0 emission in nsTextFormatter; r?froydnj draft
Tom Tromey <tom@tromey.com> - Wed, 06 Sep 2017 09:38:58 -0600 - rev 666405
Push 80394 by bmo:ttromey@mozilla.com at Mon, 18 Sep 2017 18:11:14 +0000
Bug 1388789 - clean up \0 emission in nsTextFormatter; r?froydnj nsTextFormatter unconditionally emitted a trailing \0, leading some code elsewhere to have to work around this. This changes the code to only emit it in snprintf. MozReview-Commit-ID: G3CBpAPp9Tn
a9cef178bea738b55233cc9ef811af238a1292c4: Bug 1388789 - normalize null string handling in nsTextFormatter; r?froydnj draft
Tom Tromey <tom@tromey.com> - Wed, 06 Sep 2017 08:38:44 -0600 - rev 666404
Push 80394 by bmo:ttromey@mozilla.com at Mon, 18 Sep 2017 18:11:14 +0000
Bug 1388789 - normalize null string handling in nsTextFormatter; r?froydnj The char* and char16_t* cases handled null strings differently; normalize them to both emit "(null)". MozReview-Commit-ID: IzRkc3pSSjl
cd84280eea3adcde3744f2e7ddee516ee7a5a281: Bug 1388789 - use nsTextFormatter::ssprintf in more places; r?froydnj draft
Tom Tromey <tom@tromey.com> - Wed, 06 Sep 2017 08:19:05 -0600 - rev 666403
Push 80394 by bmo:ttromey@mozilla.com at Mon, 18 Sep 2017 18:11:14 +0000
Bug 1388789 - use nsTextFormatter::ssprintf in more places; r?froydnj A few places were using snprintf where ssprintf would be more appropriate. MozReview-Commit-ID: LnBy3IcG98C
166cc3690589cd41f3240b85d2ac2694149528d9: Bug 1388789 - make nsTextFormatter runtime type-safe; r?froydnj draft
Tom Tromey <tom@tromey.com> - Fri, 01 Sep 2017 14:03:56 -0600 - rev 666402
Push 80394 by bmo:ttromey@mozilla.com at Mon, 18 Sep 2017 18:11:14 +0000
Bug 1388789 - make nsTextFormatter runtime type-safe; r?froydnj Change nsTextFormatter functions to template functions, box their arguments, and then make the formatter mostly impervious to type mismatches. Most formatting is done according to the type of the actual argument. MozReview-Commit-ID: H8WmyxFCb7s
8ae8a8eabe371c3347a118dbe3313139874a2a11: Bug 1388789 - change return values of nsTextFormatter::vs{s,v}printf; r?froydnj draft
Tom Tromey <tom@tromey.com> - Tue, 05 Sep 2017 13:17:49 -0600 - rev 666401
Push 80394 by bmo:ttromey@mozilla.com at Mon, 18 Sep 2017 18:11:14 +0000
Bug 1388789 - change return values of nsTextFormatter::vs{s,v}printf; r?froydnj nsTextFormatter::vsnprintf is defined to return uint32_t(-1) on error. However, it was not doing this. nsTextFormatter::vssprintf is defined as infallible; enforce this by having it return void. MozReview-Commit-ID: LdOhIHzRvAT
390e4a0e5ba47d20c90fe943fe1736c44d0dc109: Bug 1388789 - handle unrecognized escapes in nsTextFormatter; r?froydnj draft
Tom Tromey <tom@tromey.com> - Fri, 01 Sep 2017 08:31:49 -0600 - rev 666400
Push 80394 by bmo:ttromey@mozilla.com at Mon, 18 Sep 2017 18:11:14 +0000
Bug 1388789 - handle unrecognized escapes in nsTextFormatter; r?froydnj nsTextFormatter tried to pass unrecognized escapes in the format string through to the output. However, if the format held a width or precision, that text was not output. It seems better to me to try to preserve the format text as-is. MozReview-Commit-ID: HoBykpfzK7C
3c29dd238806448412835dbd2a38ed693a0c2952: Bug 1388789 - replace hex strings with static arrays; r?froydnj draft
Tom Tromey <tom@tromey.com> - Fri, 01 Sep 2017 06:25:11 -0600 - rev 666399
Push 80394 by bmo:ttromey@mozilla.com at Mon, 18 Sep 2017 18:11:14 +0000
Bug 1388789 - replace hex strings with static arrays; r?froydnj nsTextFormatter used nsAutoString for arrays of hex digits; but this didn't seem to provide any benefit. MozReview-Commit-ID: EYHtnAzJL8h
a58383998d489b7578842d7e40ab4be73f6a9ed9: Bug 1388789 - remove prio.h include from nsTextFormatter.h; r?froydnj draft
Tom Tromey <tom@tromey.com> - Thu, 31 Aug 2017 15:22:36 -0600 - rev 666398
Push 80394 by bmo:ttromey@mozilla.com at Mon, 18 Sep 2017 18:11:14 +0000
Bug 1388789 - remove prio.h include from nsTextFormatter.h; r?froydnj This header is not needed here. MozReview-Commit-ID: 1msozRXsHXR
f509fa6d045ac4df741b6f642d4d783dfad08b60: Bug 1388789 - make va_list nsTextFormatter private; r?froydnj draft
Tom Tromey <tom@tromey.com> - Thu, 31 Aug 2017 15:21:37 -0600 - rev 666397
Push 80394 by bmo:ttromey@mozilla.com at Mon, 18 Sep 2017 18:11:14 +0000
Bug 1388789 - make va_list nsTextFormatter private; r?froydnj The runtime type-checking rewrite of nsTextFormatter will not support va_list uses. So, make these functions private and fix the sole user. MozReview-Commit-ID: IBWALVzIcHC
ff03e5ece8436a95de837631347108d9f4743219: Bug 1391421 - Part 9 - Add a basic Robocop test for IDN domain support. r?gbrown draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 15 Sep 2017 23:29:01 +0200 - rev 666396
Push 80393 by mozilla@buttercookie.de at Mon, 18 Sep 2017 17:56:17 +0000
Bug 1391421 - Part 9 - Add a basic Robocop test for IDN domain support. r?gbrown MozReview-Commit-ID: HAT9Imh9YVf
c2bc13dd008d1daccad241c2a78af7045a72d07a: Bug 1391421 - Part 8 - Fix site identity handling. r?jwu draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 15 Sep 2017 20:43:40 +0200 - rev 666395
Push 80393 by mozilla@buttercookie.de at Mon, 18 Sep 2017 17:56:17 +0000
Bug 1391421 - Part 8 - Fix site identity handling. r?jwu "getEffectiveHost" further down expects the URI to be available - apparently this was broken ever since the original implementation. MozReview-Commit-ID: C1Q6PBYcvk3
bdbc31c842fa93c0c2421f529003394e44051d87: Bug 1391421 - Part 7 - Switch addon/theme install prompts to Unicode domains. r?jwu draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 15 Sep 2017 20:38:08 +0200 - rev 666394
Push 80393 by mozilla@buttercookie.de at Mon, 18 Sep 2017 17:56:17 +0000
Bug 1391421 - Part 7 - Switch addon/theme install prompts to Unicode domains. r?jwu MozReview-Commit-ID: HlQKTJRu0FT
80b1b1d209f0423b426b926dfe7806c3905921a0: Bug 1391421 - Part 6 - Switch context menus to Unicode domains. r?jwu draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 16 Sep 2017 15:01:09 +0200 - rev 666393
Push 80393 by mozilla@buttercookie.de at Mon, 18 Sep 2017 17:56:17 +0000
Bug 1391421 - Part 6 - Switch context menus to Unicode domains. r?jwu MozReview-Commit-ID: 6yjtRGI6Aui
01a3fd277e346cc568a3539e8213c6350eb8344b: Bug 1391421 - Part 5 - Normalise the saved "appOrigin" to Punycode. r?jwu draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 14 Sep 2017 21:09:44 +0200 - rev 666392
Push 80393 by mozilla@buttercookie.de at Mon, 18 Sep 2017 17:56:17 +0000
Bug 1391421 - Part 5 - Normalise the saved "appOrigin" to Punycode. r?jwu We already use nsUri.spec for comparison when retrieving the stored appOrigin again, so instead of storing the user-entered URL as-is, we should normalise it accordingly. Otherwise, we might end up running into mismatches between the Unicode and Punycode versions of a domain. To that extent, we move the code that stores the appOrigin into the Tab object's constructor, so we don't have to parse the URL twice. MozReview-Commit-ID: KFr8CeeOYTe
4ebd1d04e63974c6ef9f5e7a19153c8b8efc4632: Bug 1391421 - Part 4 - Switch Session Store to save the "display" URL. r?mikedeboer draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 14 Sep 2017 21:29:45 +0200 - rev 666391
Push 80393 by mozilla@buttercookie.de at Mon, 18 Sep 2017 17:56:17 +0000
Bug 1391421 - Part 4 - Switch Session Store to save the "display" URL. r?mikedeboer The URL can end up being user-visible for "Recently closed tabs" (certainly on Android, and also when hovering over an entry on Desktop, at least in the old menu bar), so we should use pretty URLs instead of Punycode. MozReview-Commit-ID: Kil2ChToYa8
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip