This was reviewed in https://bugzilla.mozilla.org/show_bug.cgi?id=1382102
Source-Repo: https://github.com/servo/servo
Source-Revision: 24270f93571e0a1254d402f1c897bcc1ebbbd459
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 85d26b1d4274515b33d5b2cb55e461e863ab4a0b
Currently Gecko treats 'auto' component value as zero for animation.
MozReview-Commit-ID: JBvTFzDw7Xy
--HG--
extra : rebase_source : 618e756bbbb66759eea50a8004740e737f8a94e1
This gets us coverage for anonymous nodes, which are currently missed.
MozReview-Commit-ID: KBOSXloteu6
--HG--
extra : rebase_source : 0f71c027f8bbbb0abd4d9e812b5d7369109e7ebc
Currently Gecko treats 'auto' component value as zero for animation.
<!-- Please describe your changes on the following line: -->
https://bugzilla.mozilla.org/show_bug.cgi?id=1387951
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
Source-Repo: https://github.com/servo/servo
Source-Revision: e0b834033d857b08985fc84e676fac636a8495dc
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c4ba04702afbd72d77f23c1b8163d26998daefb7
Iterating a LiveRange's uses in BacktrackingAllocator::computeSpillWeight() to
access UsePosition.uses_ isn't cache friendly, because it is a linked list and
each node is allocated separately. Changing the data strcture to a vector is
worse because of the overhead from frequent insertion/removing. However,
UsePostion.uses_ can't be changed after initialization, so we can pre-calculate
the spill weight when it is added to or remove from a LiveRange.
MozReview-Commit-ID: BJEvI7KBVAJ
--HG--
extra : rebase_source : 04a14fae5a455d0e70f995e80887eb09b184dc2c
Copy construction for va_list is implementation dependent, and most
likely doesn't actually work properly on some platforms. While the
wrapping in EitherParser might currently work on tier-1 platforms,
it also triggers a warning on newer GCC versions that could very well
indicate that they might not work entirely properly. Mixing va_list,
copy construction and templates variadics surely sounds like something
very fragile.
While I understand that the pending changes from bug 1351107 might be
relying on the current state of the code, I'd rather that bug be
reworked so as to please newer versions of GCC than having to figure out
what parts of that bug are still relevant after bug 1351105 and blocking
bug 1389435 further.
--HG--
extra : rebase_source : b9135990c62faf7587e646c99f3bc6ece603cb38
This requires adding a new constructor for ns[C]String that can be used to
create an IsVoid string.
--HG--
extra : rebase_source : 8cb078bd0a41e63af0d9d144b9eef369875a05e0
Web contetnt processes only need access to a small amount of schema data, but
we currently send them the approximately 600K of full schema data that is
mostly useless to them.
This patch limits the schema data sent to web content processes to what they
actually need, and sends the rest only to extension content processes.
MozReview-Commit-ID: 6G0LThNTOu1
--HG--
extra : rebase_source : 36672ad6323e6466bba3e463fa4f0a16e3fd9090
This gives JS callers access to the remote type of remote message managers.
There's currently no way for extensions to access this unless they have a
<browser> element to check the remoteType attribute of.
MozReview-Commit-ID: A8Y3ZSG3rt8
--HG--
extra : rebase_source : e024922522da9a30265f05e9a8dbf7529dfe1d81
JS code is notified when a new ContentParent is created via normal
"ipc:content-created" notifications, but can't do anything with it, since
nsIContentParent is not scriptable. This allows JS callers to retrieve the
parent process message manager, which is the normal way they interact with
content children.
MozReview-Commit-ID: 7lcZ4XkJ6uR
--HG--
extra : rebase_source : f891c0e29863fc42fc2351a791ca3f1f7e2824b9