6a7232dfba4a6817d73b071782d921915375b2fb: Bug 1384266: Generalize FlexItem::GetBaselineOffsetFromOuterCrossEdge to allow horizontal cross axis with rotated writing modes. draft
Brad Werth <bwerth@mozilla.com> - Mon, 09 Oct 2017 16:17:36 -0700 - rev 677073
Push 83680 by bwerth@mozilla.com at Mon, 09 Oct 2017 23:22:10 +0000
Bug 1384266: Generalize FlexItem::GetBaselineOffsetFromOuterCrossEdge to allow horizontal cross axis with rotated writing modes. MozReview-Commit-ID: 4dCJuMWlTUC
fe07958614e7a715c2e35a994d4dc068b04d7302: Bug 1406303 - Don't heap-allocate the global chunk radix tree. r?njn draft
Mike Hommey <mh+mozilla@glandium.org> - Fri, 06 Oct 2017 16:18:01 +0900 - rev 677072
Push 83679 by bmo:mh+mozilla@glandium.org at Mon, 09 Oct 2017 23:14:34 +0000
Bug 1406303 - Don't heap-allocate the global chunk radix tree. r?njn Now that the radix tree structure has a fixed size, we can just allocate the chunk radix tree object statically.
153dabc7d854716d7439c2f466ba7059b70f0aec: Bug 1406303 - Make the number of significant bits used by the radix tree a template parameter. r?njn draft
Mike Hommey <mh+mozilla@glandium.org> - Fri, 06 Oct 2017 15:50:00 +0900 - rev 677071
Push 83679 by bmo:mh+mozilla@glandium.org at Mon, 09 Oct 2017 23:14:34 +0000
Bug 1406303 - Make the number of significant bits used by the radix tree a template parameter. r?njn All the parameters of the radix tree (bits per level, height) are derived from the aBits argument to ::Create in a straightforward way. aBits itself is a constant at the call point, making them all constants, so we can turn all of them as constants at compile time instead of storing as data.
34d180d496601d830ca54a9735671a08cd21ff4a: Bug 1406303 - Only store 2 levels of bit sizes for the radix tree. r?njn draft
Mike Hommey <mh+mozilla@glandium.org> - Fri, 06 Oct 2017 15:24:07 +0900 - rev 677070
Push 83679 by bmo:mh+mozilla@glandium.org at Mon, 09 Oct 2017 23:14:34 +0000
Bug 1406303 - Only store 2 levels of bit sizes for the radix tree. r?njn All levels except the first are using the same size, and in some cases, even the first uses the same size. Only storing those two different sizes allows to fix the class size, while not making the code significantly more complex.
d37d48915b9d4e8feca3c925c54f2f013f27f0e8: Bug 1406303 - Simplify the calculation of AddressRadixTree's height. r?njn draft
Mike Hommey <mh+mozilla@glandium.org> - Fri, 06 Oct 2017 11:32:27 +0900 - rev 677069
Push 83679 by bmo:mh+mozilla@glandium.org at Mon, 09 Oct 2017 23:14:34 +0000
Bug 1406303 - Simplify the calculation of AddressRadixTree's height. r?njn The tree height was defined as: height = aBits / bits_per_level; if (height * bits_per_level != aBits) { height++; } What's wanted here is a height that covers all the bits, where the first level might cover less than bits_per_level. So aBits / bits_per_level gets us the height covered by levels with exactly bits_per_level bits. The tree height is one more when there are remaining bits. Put differently, we can write aBits as: aBits = bits_per_level * x + y with y < bits_per_level. We have: aBits / bits_per_level = x. height = x when y = 0, and x + 1 when y > 0. We're looking for a number z such that height = (aBits + z) / bits_per_level. Or: height = (bits_per_level * x + y + z) / bits_per_level. = x + (y + z) / bits_per_level. So we're looking for a z such that (y + z) / bits_per_level = 0 when y = 0 = 1 when y > 0 The properties of the integer division are such that the above means: 0 <= y + z < bits_per_level when y = 0 bits_per_level <= y + z < 2 * bits_per_level when y > 0 Which gives us: 0 <= z < bits_per_level bits_per_level - y <= z < 2 * bits_per_level - y when y > 0 y being < bit_per_level per the constraint further above, 2 * bits_per_level - y > bits_per_level. So all in all, we want a z such that bits_per_level - y <= z < bits_per_level with 0 < y < bits_per_level The largest value where this is true is z = bits_per_level - 1. In summary, height = (aBits + bits_per_level - 1) / bits_per_level is the same as the height as originally defined. With that formula, it's self evident that height * bits_per_level is always >= aBits, so we remove the assertion.
87ddfd91df91cc1ba09becd442b2ad7e8dbb603e: Bug 1406303 - Simplify the calculation of AddressRadixTree's bits_per_level. r?njn draft
Mike Hommey <mh+mozilla@glandium.org> - Thu, 28 Sep 2017 15:35:21 +0900 - rev 677068
Push 83679 by bmo:mh+mozilla@glandium.org at Mon, 09 Oct 2017 23:14:34 +0000
Bug 1406303 - Simplify the calculation of AddressRadixTree's bits_per_level. r?njn bits_per_level was defined as: ffs(pow2_ceil((kNodeSize / sizeof(void*)))) - 1 kNodeSize is (1U << 14) when SIZEOF_PTR is 4 (sizeof(void*) being the same). Otherwise, it's CACHELINE, which is (1U << 6). The most important part, though, is that it's always a power of 2. And it's divided by sizeof(void*) which is always a power or 2. The result of that division is thus always a power of 2, as long as kNodeSize is larger than the size of a pointer, which it is. The argument to pow2_ceil being a power of 2, pow2_ceil is a noop, so it can go away. And the argument to ffs being a power of 2, it returns one more than n that matches 1 << n == value. So overall the expression returns the number of shifts for kNodeSize / SIZEOF_PTR. Transforming kNodeSize to a number of shifts/power of 2, the expression can then be simplified as kNodeSize2Pow - SIZEOF_PTR_2POW.
ef0e821b14d612d290d9284d710feb6c873b4a33: Bug 1406303 - Turn malloc_rtree_t into a C++ class. r?njn draft
Mike Hommey <mh+mozilla@glandium.org> - Fri, 06 Oct 2017 10:49:24 +0900 - rev 677067
Push 83679 by bmo:mh+mozilla@glandium.org at Mon, 09 Oct 2017 23:14:34 +0000
Bug 1406303 - Turn malloc_rtree_t into a C++ class. r?njn The only semantic change is in the value returned by Set, which now returns whether the value could be set or not.
7c35c4b5fceb4e49ce87d063bb583965c1df99e2: Bug 1406303 - Refactor malloc_rtree_get/set. r?njn draft
Mike Hommey <mh+mozilla@glandium.org> - Thu, 28 Sep 2017 12:18:14 +0900 - rev 677066
Push 83679 by bmo:mh+mozilla@glandium.org at Mon, 09 Oct 2017 23:14:34 +0000
Bug 1406303 - Refactor malloc_rtree_get/set. r?njn There is a lot of redundancy between malloc_rtree_get and malloc_rtree_set. Essentially, they both look up a slot, and either get a value or set a value in that slot. malloc_rtree_get doesn't create a tree path for the slot when it doesn't exist. And the MALLOC_RTREE_GET_GENERATE macro machinery makes malloc_rtree_get retry with a lock and validate both results agree in debug builds. By introducing a malloc_rtree_get_slot function that returns a slot, optionally creating a tree path to it, we remove the redundancy between _get and _set, and we can avoid the macro machinery as well.
500e836f9415ef60501e76452af531f56b532f0b: Bug 1407077 - remove background color for highlighted devtools tabs;r=gl draft
Julian Descottes <jdescottes@mozilla.com> - Tue, 10 Oct 2017 01:05:35 +0200 - rev 677065
Push 83678 by jdescottes@mozilla.com at Mon, 09 Oct 2017 23:06:09 +0000
Bug 1407077 - remove background color for highlighted devtools tabs;r=gl MozReview-Commit-ID: 7r2tCtFiTuA
944a57f9aa0c3ebec7e2f7d8f9c66f9c22ce36af: Bug 1407077 - use photon colors for highlighted devtools toolbar icons;r=gl draft
Julian Descottes <jdescottes@mozilla.com> - Thu, 05 Oct 2017 17:07:24 +0200 - rev 677064
Push 83678 by jdescottes@mozilla.com at Mon, 09 Oct 2017 23:06:09 +0000
Bug 1407077 - use photon colors for highlighted devtools toolbar icons;r=gl MozReview-Commit-ID: LCEArSoizyk
7070e658d99cfb47130fa9f3fafad145f2f5fc01: Bug 1407056: Part 3 - Test that CSP overrides apply correctly based on triggering principals. r?bz draft
Kris Maglione <maglione.k@gmail.com> - Sat, 07 Oct 2017 14:53:11 -0700 - rev 677063
Push 83677 by maglione.k@gmail.com at Mon, 09 Oct 2017 23:00:36 +0000
Bug 1407056: Part 3 - Test that CSP overrides apply correctly based on triggering principals. r?bz MozReview-Commit-ID: EbGsI3keeG6
dfdb07a9cfe17a79e9d7da01aeeb3d4cf6d59631: Bug 1407056: Part 2 - Override page CSP for loads by expanded principals. r?bz,krizsa draft
Kris Maglione <maglione.k@gmail.com> - Sat, 07 Oct 2017 14:53:30 -0700 - rev 677062
Push 83677 by maglione.k@gmail.com at Mon, 09 Oct 2017 23:00:36 +0000
Bug 1407056: Part 2 - Override page CSP for loads by expanded principals. r?bz,krizsa Per the CSP specification, content injected by extensions is meant to be exempt from page CSP. This patch takes care of the most common case of content injected by extension content scripts, which always have expanded principals which inherit from the page principal. In a follow-up, we'll probably need to extend the exemption to stylesheet content loaded by extension codebase principals. MozReview-Commit-ID: GlY887QAb5V
605f440ebf11de43e6d25f84400ac10a012818ed: Bug 1407056: Part 1 - Provide more consistent principal/origin URL to content policies. r?bz,ckershb draft
Kris Maglione <maglione.k@gmail.com> - Sat, 07 Oct 2017 13:24:28 -0700 - rev 677061
Push 83677 by maglione.k@gmail.com at Mon, 09 Oct 2017 23:00:36 +0000
Bug 1407056: Part 1 - Provide more consistent principal/origin URL to content policies. r?bz,ckershb We're currently fairly vague and inconsistent about the values we provide to content policy implementations for requestOrigin and requestPrincipal. In some cases they're the triggering principal, sometimes the loading principal, sometimes the channel principal. Our existing content policy implementations which require or expect a loading principal currently retrieve it from the context node. Since no current callers require the principal to be the loading principal, and some already expect it to be the triggering principal (which there's currently no other way to retrieve), I chose to pass the triggering principal whenever possible, but use the loading principal to determine the origin URL. As a follow-up, I'd like to change the nsIContentPolicy interface to explicitly receive loading and triggering principals, or possibly just LoadInfo instances, rather than poorly-defined request origin/principal/context args. But since that may cause trouble for comm-central, I'd rather not do it as part of this bug. MozReview-Commit-ID: LqD9GxdzMte
50821c9a15c4ac68c637f61b9a3e98b22d6de013: Bug 1406278: Part 8b - Use subject principal as triggering principal in style <link> "href" attribute. r=bz draft
Kris Maglione <maglione.k@gmail.com> - Thu, 05 Oct 2017 19:40:48 -0700 - rev 677060
Push 83677 by maglione.k@gmail.com at Mon, 09 Oct 2017 23:00:36 +0000
Bug 1406278: Part 8b - Use subject principal as triggering principal in style <link> "href" attribute. r=bz MozReview-Commit-ID: LWMkBcB4WIg
01703e3a66540163b80bbc4a2aafe3f5ca5c69af: Bug 1406278: Part 8a - Cleanup some uses of CallQueryInterface. r=bz draft
Kris Maglione <maglione.k@gmail.com> - Thu, 05 Oct 2017 19:06:54 -0700 - rev 677059
Push 83677 by maglione.k@gmail.com at Mon, 09 Oct 2017 23:00:36 +0000
Bug 1406278: Part 8a - Cleanup some uses of CallQueryInterface. r=bz MozReview-Commit-ID: 20yDJiKLJav
aa1aa5378fe1f5810c99a1cfc3e6728692ce860c: Bug 1406278: Part 7 - Use subject principal as triggering principal in <input> "src" attribute. r=bz draft
Kris Maglione <maglione.k@gmail.com> - Thu, 05 Oct 2017 16:19:19 -0700 - rev 677058
Push 83677 by maglione.k@gmail.com at Mon, 09 Oct 2017 23:00:36 +0000
Bug 1406278: Part 7 - Use subject principal as triggering principal in <input> "src" attribute. r=bz MozReview-Commit-ID: 8DZOwqBrA2i
f43b61f3deb3ccca44244c697e614e87e37de600: Bug 1406278: Part 6 - Use subject principal as triggering principal in <source> "srcset" attribute for <picture>. r=bz draft
Kris Maglione <maglione.k@gmail.com> - Thu, 05 Oct 2017 15:59:15 -0700 - rev 677057
Push 83677 by maglione.k@gmail.com at Mon, 09 Oct 2017 23:00:36 +0000
Bug 1406278: Part 6 - Use subject principal as triggering principal in <source> "srcset" attribute for <picture>. r=bz MozReview-Commit-ID: DFq3k9PSOgA
d6223f44eededd0b2f1f061085eb3e45bd4d94e6: Bug 1406278: Part 5b - Use subject principal as triggering principal in <source> "src" attribute for <audio>/<video>. r=bz draft
Kris Maglione <maglione.k@gmail.com> - Thu, 05 Oct 2017 15:28:22 -0700 - rev 677056
Push 83677 by maglione.k@gmail.com at Mon, 09 Oct 2017 23:00:36 +0000
Bug 1406278: Part 5b - Use subject principal as triggering principal in <source> "src" attribute for <audio>/<video>. r=bz MozReview-Commit-ID: zZCXpvs719
0f656f0d6889dbf1060ed6315a01b2415c4d6f9e: Bug 1406278: Part 5a - Use subject principal as triggering principal in <audio>/<video> "src" attribute. r=bz draft
Kris Maglione <maglione.k@gmail.com> - Thu, 05 Oct 2017 14:47:09 -0700 - rev 677055
Push 83677 by maglione.k@gmail.com at Mon, 09 Oct 2017 23:00:36 +0000
Bug 1406278: Part 5a - Use subject principal as triggering principal in <audio>/<video> "src" attribute. r=bz MozReview-Commit-ID: A1JixlTeZGq
43ccca634c55f44183d3f3ccfd90562fb8d29ddd: Bug 1406278: Part 4 - Use subject principal as triggering principal in <iframe>/<frame> "src" attribute r=bz draft
Kris Maglione <maglione.k@gmail.com> - Wed, 04 Oct 2017 22:59:44 -0700 - rev 677054
Push 83677 by maglione.k@gmail.com at Mon, 09 Oct 2017 23:00:36 +0000
Bug 1406278: Part 4 - Use subject principal as triggering principal in <iframe>/<frame> "src" attribute r=bz MozReview-Commit-ID: AgxZmfRvfTR
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip