Making the job take longer in favour of reducing the variability of test results makes sense to me.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1d8e78720b06823e7f77b52a2b8fbd805d2cf2c0
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6cfe6c5831f0cd6a5ad353ff2262e80936c55c02
This will make it easier to handle it properly for Shadow DOM, though this patch
doesn't do that.
This also makes some method inline and infallible for convenience, since nobody
checks the errors anyway.
MozReview-Commit-ID: Hq3erAUs5tf
This was just an oversight when adding Stylo bindgen support to |mach
bootstrap| (I assume).
MozReview-Commit-ID: 89N6omXGUdy
--HG--
extra : rebase_source : 8055d69eea317d83d64d481708f2d77e544db688
The heuristic simply fails for clang as shipped in Android NDKs: those
clang binaries can't target any non-Android host.
MozReview-Commit-ID: 6AhOJxE3boW
--HG--
extra : rebase_source : 2c8b59c15a7a7e9803f5447fc8f41fc843b2e647
Right now Gecko uses a whole `Stylist` for stuff like XBL / Shadow DOM.
That's not great, because it has tons of unrelated logic, and also eats up a lot of memory. Also, it prevents us to optimize style changes in shadow hosts the same way we do for the document.
These patches mostly rejigger stuff around so that you can define a `DocumentStylesheetSet` and then an `AuthorStylesheetSet`, which would contain just the Shadow DOM sheets / XBL resource sheets.
It still doesn't introduce any use for the later, but that will come later.
There's a patch in this PR that requires Gecko changes, posted in https://bugzilla.mozilla.org/show_bug.cgi?id=1436798.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6b1a74672d6b9d9c55b027b147b0a6eb8f727bfd
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 35cd629f88c24439c615e283265dbb78d33279b7
Two things have changed. One, Brew's java package became Java 9,
which doesn't work for building on Android. Two, Brew's cask system
also changed, requiring some small updates.
In order to actually use the install java toolchain, we need to use
the --with-java-bin-path configure option, which required some small
tweaks to the suggested mozconfigs.
MozReview-Commit-ID: JlZpdqaOkp0
--HG--
extra : rebase_source : c2828139843b6e0b8d2f0c3141d4d9e5b0b83b4f
* The number is no longer selected on number input focus
MozReview-Commit-ID: AmR5c6YKTCP
--HG--
extra : rebase_source : fdaab23fca57f361c9185191d9c30e047375cbe8
Changing the transaction id allocator is now handled better in
ClientLayerManager than before in that it resets the transaction id on
the new allocator to match the old allocator and avoid discontinuities
in the transaction ids. We should apply this behaviour to
WebRenderLayerManager as well, because WebRenderLayerManager was
assuming that any time the allocator changed it would automatically
start the transaction id at 1, which is not the case. In particular,
when navigating to something in the bfcache, we can reuse a pre-existing
refresh driver which might have a transaction id already greater than 1.
MozReview-Commit-ID: 8IUn1Dhnh7c
--HG--
extra : rebase_source : 0e98c96d9636c3a3ee0489ff6b6161bce7677dd7
If there is an active provider which has yet to produce a frame, any
calls to SurfaceCache::Lookup will return MatchType::PENDING. If
RasterImage::Lookup gets the above result while given FLAG_SYNC_DECODE,
it will attempt to start a new decoder. It is entirely possible that
when we try to insert the new provider into the SurfaceCache, it cannot
because the original provider finally did produce something. In that
case we should abandon attempting to redecode and retry our lookup.