Two bools are not converted because they are used with AutoRestore.
MozReview-Commit-ID: AjU61eiMtlQ
--HG--
extra : rebase_source : d1706adc6f14a1a93d1461dd22df0a95043fcca4
This adds reftest support to the test package mach environment. It will allow
developers to easily run reftests after checking out an interactive worker.
MozReview-Commit-ID: fBAbfuG5XQ
--HG--
extra : rebase_source : 84b4a9fff7f2f27a325ffad4af1de7726bad296e
This adds the 'xpcshell-test' command to the mach environment found in the test
package. This will allow developers to easily run xpcshell after checking out
and interactive worker.
MozReview-Commit-ID: fBAbfuG5XQ
--HG--
extra : rebase_source : 71077c9142f33843ed87d4bc4617a780f775939b
The test path structure is slightly different in the test package compared to a srcdir. So we may need
to normalize the specified paths such that they are relative to a srcdir. Because every test harness
needs to do this, this method is being added to the bootstrap for re-use.
MozReview-Commit-ID: fBAbfuG5XQ
--HG--
extra : rebase_source : b4cedaecfeab777971c9840e932c0aa2bff88240
When running test harnesses from the test package, the firefox binary will live somewhere
outside of the mach context. There are two common situations where a developer might be
running from a test package:
1) From a mozharness context
2) From an objdir context
This patch will attempt to detect either of those situations and automagically find the
firefox binary.
MozReview-Commit-ID: fBAbfuG5XQ
--HG--
extra : rebase_source : 53c87a83bacf6b90a5849559f5616b7a45970627
These numbers are only used to calculate a percentage, so they don't really
need to be 64-bit long.
MozReview-Commit-ID: FfdyStjGITL
--HG--
extra : rebase_source : 704d7664a3462f68f2c495e3b5d66f71180d290b
VideoPlaybackQuality was fed uint64_t's, now it should be given uint32_t's.
Note that FrameStatistics currently provide uint32_t's, so we are fine now;
nevertheless I added a static_assert to verify that and ensure it stays true.
MozReview-Commit-ID: I0dgP1K4lg3
--HG--
extra : rebase_source : f8d673db0cd45d2b3ae03c092dff217e5d7ebbee
Because VideoPlaybackQuality attributes are exposed as 'unsigned long' (aka
uint32_t) in the webidl interface, it would be dangerous to accept and store
them as uint64_t in the class.
MozReview-Commit-ID: EhX4lhTbA3c
--HG--
extra : rebase_source : ed1e745c7d69babe6875677e3c8a16a9d6f3172c
The asserts are:
###!!! ASSERTION: Bounds computation mismatch: 'mContainerBounds.IsEqualInterior(mAccumulatedChildBounds)', /layout/base/FrameLayerBuilder.cpp, line 4887
###!!! ASSERTION: bad aListVisibleBounds: 'r.GetBounds().IsEqualInterior(aListVisibleBounds)', /layout/base/nsDisplayList.cpp, line 1637
They happen because we have a wrap list item that contains an out of flow frame with no saved clip data. So the patch for this bug changes the scroll clip of the wrap list item from the scroll clip induced by the root scroll frame to the null scroll clip. All of the display items that the wrap list contains have the root scroll frame scroll clip, so this causes the scroll clipped bounds for the wrap list item to expand to the whole content area. These expanded bounds of the wrap list item get incorporated into the bounds of a parent transform item. Later the wrap list item is flattened away, and so it's no longer around to provide the expanded bounds, leading to the assertions.
I've thought through options like changing how scroll clipped bounds work for wrap list items, but I can't seem to find any solution that would be consistent. The best thing would be to get the proper clip on out of flows we are going to descend into, but I can't think of a good way to do that either in this case (or in general).
