Bug 1466231 Part 5: Update a wpt reftest to remove its reliance on fitting inline-blocks into a too-narrow space. r=dbaron This reftest currently uses a container that is 1 pixel narrower than needed to fit two blocks side-by-side. That's useful for making the first two blocks land on separate lines, but it makes the test rely on the browser forcing the first inline block on a line to fit even if there is no space for it (in this case, the block that should be pushed to the right). MozReview-Commit-ID: IxtOR2yFNn6

Bug 1466231 Part 4: Correct the size of an element in a submitted WPT test, that was only passing due to this bug. r=dbaron This reftest was submitted by me with an incorrect size for the shape element. It was only passing in Firefox due to a related bug, which is now fixed. The updated size makes this test construct a polygon similar to the one in the shape-outside-polygon-012 test, which was the original intent. MozReview-Commit-ID: CuXe2vTmjS0

Bug 1466231 Part 3: Change some reftests to expected pass, one with fuzziness. r=dbaron MozReview-Commit-ID: 2g6EvOuZqRg

Bug 1466231 Part 2: Add a submitted WPT reftest. r=dbaron MozReview-Commit-ID: 4OtqxvM4Gen

Bug 1466231 Part 1: Change nsBlockFrame::PlaceLine to accept an nsFlowAreaRect and update flags if it shrinks the area due to a float. r=dbaron MozReview-Commit-ID: 4stQQfboUl7

Bug 1468025 - Define lazy getter for TCPListener in Marionette component. r=whimboo This patch reorganises imports and getter definitions to match style used elsewhere, and defines TCPListener as a lazy getter. MozReview-Commit-ID: Dq2ufYzVcvE

Backed out 3 changesets (bug 1466490) for ESlint failures on test_GeckoView_ScalarSemantics. CLOSED TREE Backed out changeset 5f13ed9de8a3 (bug 1466490) Backed out changeset 95048dd368eb (bug 1466490) Backed out changeset e3891caf027f (bug 1466490)

Bug 1466490 - Add multi-process xpcshell test for scalar semantics. r=Dexter This follows the documentation example: * Scalar deserialization is started * “test” scalar is incremented by “10” by the application -> The operation [test, add, 10] is recorded into the list. * The state of the “test” scalar is loaded off the persistence file, and the value “14” is set. * Deserialization is finished and the pending operations are applied. * The “test” scalar is incremented by “10”, the value is now “24” It does that in both the parent and the content process. MozReview-Commit-ID: FSIkuW2xYjD

Bug 1466490 - Extract common test functionality into a header. r=Dexter MozReview-Commit-ID: 81Gj0FyCBqG

Bug 1466490 - Actually record non-main scalars on the main process after deserialization/recording. r=Dexter MozReview-Commit-ID: HNGq5kVVc3k

Bug 1466486 - Apply focus style to devtools selection button. r=nchevobbe The bug 1444793 introduced the focus devtools button style instead of using the outline style. However, devtools selection button didn't use this style. This patch apply the focus style to the devtools selection buttons. MozReview-Commit-ID: DQEDMRSThMr

Bug 1344286 - Fix eslint errors from devtools files ignored previously; r?ntim MozReview-Commit-ID: CXVyorSle4l

Bug 1469076: Fix the broken invariants of the rule node cache. r?xidorn We were spuriously reframing the <shadow> because it initially shared style with the <br>, which ended up being display: none, while the <shadow> should've been display: contents from the beginning. lookup_by_rules seems pretty prone to obscure bugs, and also it's pretty complex... Probably we should try to get rid of it, I'm unconvinced that it's worth it. Even with that, in a normal restyle the <details> wouldn't have ended up with a style. It of course never had it before the reframe because the <shadow> was display: none, but that doesn't mean it shouldn't have gotten one, since we detected we needed to go through kids in: https://searchfox.org/mozilla-central/rev/6eea08365e7386a2b81c044e7cc8a3daa51d8754/servo/components/style/matching.rs#500 That code did happen, but since it's an animation-only restyle, we don't look at unstyled stuff. That looks somewhat fishy, but I guess for now it's fine as long as display isn't animatable. MozReview-Commit-ID: B6NMSTNOKgK

Bug 1422225: Test updates. r?xidorn MozReview-Commit-ID: J2tag9ulUon

Bug 1422225: Evaluate MediaConditions, and glue it all together. r?xidorn MozReview-Commit-ID: 3MThE2FvfDf

Bug 1422225: Add serialization code for MediaCondition. r?xidorn MozReview-Commit-ID: AxQQottV1hG

Bug 1422225: Add code to parse media conditions. r?xidorn Still unused. MozReview-Commit-ID: IQfxObw9BV5

Bug 1422225: Rename Expression to MediaFeatureExpression. r?xidorn Which is more appropriate, given it represents a `<media-feature>` per spec, and expression is a bit overloaded :) MozReview-Commit-ID: Fed1nJhHxDu

Bug 1422225: Allow parsing operators in media feature expressions. r?xidorn The only bit from the spec which I haven't implemented to my knowledge is the bit that allows you to swap the position of the media feature and the value, because it unnecessarily complicates parsing (we parse the value in terms of the feature), and I don't think it's useful given how easy it is to switch from, e.g., `(500px > width)` to `(width <= 500px)`. I filed https://github.com/w3c/csswg-drafts/issues/2791 about it. MozReview-Commit-ID: 6xrdVl87S9X

HTMLSlotElement::FromNode is a bit of a footgun. MozReview-Commit-ID: ED9quoYDQAJ