d3fc822d7cf65b08c5e03bb63cc1c38ea0ea8093: Bug 1394035 - stylo: Update @page rule test expectations r=emilio
Nazım Can Altınova <canaltinova@gmail.com> - Mon, 28 Aug 2017 22:43:28 -0700 - rev 660405
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1394035 - stylo: Update @page rule test expectations r=emilio MozReview-Commit-ID: IQNHKh3Ubv
c6d22c5e19ab5bcbfadd012dc6f712839c613774: servo: Merge #18398 - stylo: Pass the @page values to precomputed pseudo element declarations (from canaltinova:at-page-rule); r=emilio
Nazım Can Altınova <canaltinova@gmail.com> - Wed, 06 Sep 2017 16:40:33 -0500 - rev 660404
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
servo: Merge #18398 - stylo: Pass the @page values to precomputed pseudo element declarations (from canaltinova:at-page-rule); r=emilio We were parsing @page rules correctly and serializing for cssom when we we need. But we weren't actually including them to the pseudo element declarations when we need to print a page. Reviewed by emilio on Bugzilla. --- - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix [Bug 1394035](https://bugzilla.mozilla.org/show_bug.cgi?id=1394035) Source-Repo: https://github.com/servo/servo Source-Revision: 094502e55f246b7c21d788385dda5c350ecf783a
7efa30ab3893c3eb67e99ca115200c7e403bf941: Bug 1397500 - Disable the ActiveElementUsesStyle optimization for stylo. r=emilio
Bobby Holley <bobbyholley@gmail.com> - Wed, 06 Sep 2017 15:20:52 -0700 - rev 660403
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1397500 - Disable the ActiveElementUsesStyle optimization for stylo. r=emilio MozReview-Commit-ID: 20aqaFv9fxE
48ed0961198671541c2a91a6d6cdf18758a6ace0: Bug 1393574 - fix flexible spacers not being removable in some circumstances, r=jaws
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Wed, 06 Sep 2017 10:02:44 +0100 - rev 660402
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1393574 - fix flexible spacers not being removable in some circumstances, r=jaws The goal of this patch is to ensure that: - in default placements, specials have no unique ids - in actual placements as stored by CUI, they do - we reset the counter for those unique ids on reset. - we re-number specials when building an area (like on startup, or when resetting), ensuring that the actual nodes always match the placements for a given area. - we force saves after resetting, to ensure that the gNewElementCount is always persisted correctly. This last part will also fix bug 1393661 MozReview-Commit-ID: HAS5J5ZSgB5
4f17343164b66db561be6371496c544f0c202a2d: Bug 1396723 - Use DoublyLinkedList in mozjemalloc. r=froydnj
Mike Hommey <mh+mozilla@glandium.org> - Sat, 02 Sep 2017 08:55:42 +0900 - rev 660401
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1396723 - Use DoublyLinkedList in mozjemalloc. r=froydnj Mozjemalloc uses its own doubly linked list, which, being inherited from C code, doesn't do much type checking, and, in practice, is rather similar to DoublyLinkedList, so use the latter instead.
b744eba9ca787a5f28972463ba9cfeb36f5b49a2: Bug 1396723 - Simplify the trait users of DoublyLinkedList need to define. r=froydnj
Mike Hommey <mh+mozilla@glandium.org> - Sat, 02 Sep 2017 08:09:58 +0900 - rev 660400
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1396723 - Simplify the trait users of DoublyLinkedList need to define. r=froydnj While the flexibility of the current trait is nice, it's actually not used to its fullest anywhere, and is boilerplate-y. While it is useful to be able to put the links anywhere, there's not much usefulness from being able to split mNext and mPrev. So instead of a trait that allows to get/set mNext and mPrev independently, we just use a trait that tells how to get a reference to a DoublyLinkedListElement from a list element itself.
56d353e23439a1b77a7011289408fbed894af621: Bug 1397406 - Use BuildReader helper in `mach test`; r=dustin
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 12:26:15 -0700 - rev 660399
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1397406 - Use BuildReader helper in `mach test`; r=dustin Now that we have a helper function to obtain a BuildReader, let's put it to use. MozReview-Commit-ID: 7V3RsWs5TPu
e9416a307987f144f994dfeb6ed00b3277068279: Bug 1397406 - Add a helper function to retrieve a BuildReader; r=dustin
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 12:18:51 -0700 - rev 660398
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1397406 - Add a helper function to retrieve a BuildReader; r=dustin The code for obtaining a BuildReader for evaluating moz.build files is generic and non-trivial. We already had a custom implementation for `mach file-info` that implemented support for Mercurial integration. Bug 1383880 will introduce a second consumer. So this commit factors out the "obtain a BuildReader" logic into a reusable function on our base MozbuildObject class. This makes it easily available to various parts of the build system and mach commands. As part of the change, we detect when ``.`` is being used as the revision and verify the working directory is clean. This behavior can be disabled via argument if unwanted. But it's useful by default to ensure consumers aren't expecting to read uncommitted changes. MozReview-Commit-ID: LeYFqAb3HAe
da68a5ff28d0cd132e031b1a67577a19274c01df: Bug 1397406 - Add Repository method to determine if working directory clean; r=dustin
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 12:15:12 -0700 - rev 660397
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1397406 - Add Repository method to determine if working directory clean; r=dustin This is generally useful functionality to have. A consume will be introduced in an upcoming commit. MozReview-Commit-ID: 4arTMfJSiEC
caccc7951f5bd8f0d4b840da0a7b9ea4a5d4df84: Bug 1397406 - Don't mark finder as a protected attribute; r=dustin
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 12:13:38 -0700 - rev 660396
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1397406 - Don't mark finder as a protected attribute; r=dustin It seems reasonable to expose this outside of the BuildReader. MozReview-Commit-ID: 4paDbYl9dEd
4ef48b1ea11bf9ff695a73713d58ed936fa3a140: Bug 1397415: Sync shield-recipe-client v73 from GitHub (commit e96eea7) r=Gijs
Michael Kelly <mkelly@mozilla.com> - Wed, 06 Sep 2017 12:50:43 -0700 - rev 660395
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1397415: Sync shield-recipe-client v73 from GitHub (commit e96eea7) r=Gijs PRs included in this patch: - #1002: Fix bug 1393257: Stop in-progress studies when opt-out pref changes. https://github.com/mozilla/normandy/pull/1002 - #1010: Bug 1392738: Update how we open the new preferences UI. https://github.com/mozilla/normandy/pull/1010 - #1024: Bug 1371350: Delay almost all startup tasks until after sessionstore-windows-restored https://github.com/mozilla/normandy/pull/1024 - #1029: Fix #856: Add type parameter to preference experiment annotations. https://github.com/mozilla/normandy/pull/1029 MozReview-Commit-ID: 7T3MgLMMsiE
2b2606848e3b999736c7550db2ec68cc8af25be3: servo: Merge #18395 - Use a 1-element smallvec for selector lists (from jdm:selector-smallvec); r=SimonSapin
Josh Matthews <josh@joshmatthews.net> - Wed, 06 Sep 2017 15:33:20 -0500 - rev 660394
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
servo: Merge #18395 - Use a 1-element smallvec for selector lists (from jdm:selector-smallvec); r=SimonSapin Profiling shows this reducing parsing time by a few milliseconds on the tp6 facebook case. The gtest benchmark with the same concatenated stylesheets also shows a significant improvement. --- - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] There are tests for these changes Source-Repo: https://github.com/servo/servo Source-Revision: 5e321cadf3308d21c4bc7de5061c5fc08670c18a
252f4499d3725ced8761b96c44cc6edd5e3b74ef: Bug 1382440 - Fix CPUUsageWatcher on OSX and Linux r=froydnj
Doug Thayer <dothayer@mozilla.com> - Mon, 28 Aug 2017 14:00:22 -0700 - rev 660393
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1382440 - Fix CPUUsageWatcher on OSX and Linux r=froydnj Properly enclose all relevant details of CPUUsageWatcher in ifdefs which control whether it should be active or not. Additionally, apparently clock_gettime is not defined on OSX prior to 10.12, so this is failing to compile for OSX on the build server, but not locally. However, clock_get_time and getrusage should cover our use cases sufficiently. MozReview-Commit-ID: Ffi6yXLb9gO
b84af3674b4968066d8a41e3670ea0f57bce1381: Bug 1382440 - Watch CPU usage in BHR r=froydnj
Doug Thayer <dothayer@mozilla.com> - Mon, 24 Jul 2017 13:46:09 -0700 - rev 660392
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1382440 - Watch CPU usage in BHR r=froydnj We would like to be able to see if a given hang in BHR occurred under high CPU load, as this is an indication that the hang is of less use to us, since it's likely that the external CPU use is more responsible for it. The way this works is fairly simple. We get the system CPU usage on a scale from 0 to 1, and we get the current process's CPU usage, also on a scale from 0 to 1, and we subtract the latter from the former. We then compare this value to a threshold, which is 1 - (1 / p), where p is the number of (virtual) cores on the machine. This threshold might need to be tuned, so that we require an entire physical core in order to not annotate the hang, but for now it seemed the most reasonable line in the sand. I should note that this considers CPU usage in child or parent processes as external. While we are responsible for that CPU usage, it still indicates that the stack we receive from BHR is of little value to us, since the source of the actual hang is external to that stack. MozReview-Commit-ID: JkG53zq1MdY
bc13c43f67712786325bdea324246bea41a0b076: Backed out 2 changesets (bug 1396723) for build failures in TestDoublyLinkedList.cpp a=backout
Wes Kocher <wkocher@mozilla.com> - Wed, 06 Sep 2017 14:30:41 -0700 - rev 660391
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Backed out 2 changesets (bug 1396723) for build failures in TestDoublyLinkedList.cpp a=backout Backed out changeset 1c0f9d069ade (bug 1396723) Backed out changeset 6ca94a450b81 (bug 1396723) MozReview-Commit-ID: 2w3WTvhpg6J
a5aa81a626da9e7cf14f6600ee8ac0ed9b6cee1f: Bug 1397460 - Don't throw for a failure in cpows_child.js. r=billm
Andrew McCreight <continuation@gmail.com> - Wed, 06 Sep 2017 13:45:22 -0700 - rev 660390
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1397460 - Don't throw for a failure in cpows_child.js. r=billm When ok() is passed false, we send a message to the parent, which will cause the test to fail. Throwing in this helper in the child just makes the test hang for a while. MozReview-Commit-ID: 4gwBACPYfDO
ad5c7dbaa4d6c2f31c3b5a89c159f781a2f92902: Bug 1387130 - Use original tabstrip scrolling behaviour when using scrollbuttons. r=dao
Mike Conley <mconley@mozilla.com> - Wed, 06 Sep 2017 13:28:48 -0400 - rev 660389
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1387130 - Use original tabstrip scrolling behaviour when using scrollbuttons. r=dao In bug 1356705, we switched scrollbox to use CSS smooth scroll when the scrollbox is configured to scroll smoothly. This caused the tab strip to scroll with a "pulse" when using the arrow scrollbuttons. This is because we scroll by a single tab each time, as opposed to scrolling by pixels. This reverts part of bug 1356705 so that we use instant scrolling instead of smooth scrolling in the scrollbuttons case, which returns the original behaviour of the strip without the pulse. MozReview-Commit-ID: D8QQ8kQ7AjM
1c0f9d069aded626bdd92b80996470ea778c8d9d: Bug 1396723 - Use DoublyLinkedList in mozjemalloc. r=froydnj
Mike Hommey <mh+mozilla@glandium.org> - Sat, 02 Sep 2017 08:55:42 +0900 - rev 660388
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1396723 - Use DoublyLinkedList in mozjemalloc. r=froydnj Mozjemalloc uses its own doubly linked list, which, being inherited from C code, doesn't do much type checking, and, in practice, is rather similar to DoublyLinkedList, so use the latter instead.
6ca94a450b810dce5cbb82b2fa13f3a34630a27b: Bug 1396723 - Simplify the trait users of DoublyLinkedList need to define. r=froydnj
Mike Hommey <mh+mozilla@glandium.org> - Sat, 02 Sep 2017 08:09:58 +0900 - rev 660387
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1396723 - Simplify the trait users of DoublyLinkedList need to define. r=froydnj While the flexibility of the current trait is nice, it's actually not used to its fullest anywhere, and is boilerplate-y. While it is useful to be able to put the links anywhere, there's not much usefulness from being able to split mNext and mPrev. So instead of a trait that allows to get/set mNext and mPrev independently, we just use a trait that tells how to get a reference to a DoublyLinkedListElement from a list element itself.
74131a35a149450b24ca17d4bde05abee558a99f: Bug 1395729 - Disable frame merging for nsTextFrame. r=mattwoodrow
Alexis Beingessner <a.beingessner@gmail.com> - Wed, 06 Sep 2017 13:49:31 -0400 - rev 660386
Push 78390 by bmo:emilio@crisal.io at Wed, 06 Sep 2017 23:04:15 +0000
Bug 1395729 - Disable frame merging for nsTextFrame. r=mattwoodrow MozReview-Commit-ID: C0kq5IYgUMG
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip