There are essentially four categories of jobs that have dependencies on
sccache currently and that shouldn't:
- jobs that don't compile anything. They just inherited the dependency
because they were using the same tooltool manifests as compiling
builds.
- jobs that don't use sccache. Ideally, we'd make them use sccache, but
things are not currently setup to make that easy, so we'll keep that for
later.
- jobs that explicitly disable sccache through needs-sccache: false.
Like above, ideally, they would use sccache.
- jobs that can't use sccache. Those are hazard jobs, that rely on a GCC
plugin and AIUI on a global knowledge of the code, which the plugin needs
to see. Caching would break that.
--HG--
extra : rebase_source : 77455b9f0a58919838c8c64c36aa1db99baf8c7e
In case of websites manipulating the browser's history via history.pushState
there will be no usual page load events fired. Instead listeners for popstate
events have to be used.
When such an event occurs we can directly return because the browser will
not load the underlying page. This only happens when navigating to another
page first, or restarting Firefox.
MozReview-Commit-ID: 3PceeYK9Co7
--HG--
extra : rebase_source : 30c162f72279712920a96ebc2076db27d01c41b6
the PreTraverse stuff is all about ticking animations, which isn't something we
want to do when we're trying to get styles synchronously in the frame
constructor.
MozReview-Commit-ID: L6lw4ef4Jdk
This patch ensures that we push clips in WR for each display item,
reflecting the display item's clip chain as computed in Gecko. A display
item will often share part or most of its clip chain with other display
items, so we try to reuse the corresponding WR clip ids as much as we
can instead of defining new duplicated clips.
MozReview-Commit-ID: LkBh8LIpQ4J
--HG--
extra : rebase_source : 5af1de0931f1d059e98b5c66b15988961503e114
As silly as it may seem to specify font-sizes using viewport units, we weren't
handling zoom for them correctly either.
Bug: 1388588
Reviewed-by: Manishearth
MozReview-Commit-ID: 3Q6phYAu5CE
Source-Repo: https://github.com/servo/servo
Source-Revision: 1457f999099b74df8822750ff16628443402d408
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f0f0bcbbd8321608f814b01e2522c5f9e6b43de6
This fixes the testcase in the bug, which removes and reinserts
some elements. Our invariants require us not to set the dirty
descendants bits on unstyled elements.
MozReview-Commit-ID: 1eESZjNSURG
This was already marked fuzzy but now the difference between the test and
reference images is even more pronounced. Technically this might still be fuzzable
because the thickness of the text (which is what is different) is not what the
test is testing for. But if we fuzz it the fuzz numbers would be so high that
legitimate failures might get fuzzed as well, so it's better to just mark it
failing for now and deal with it later.
MozReview-Commit-ID: 3Wt32XB1TWG
--HG--
extra : rebase_source : 5310a5b2deb187dcf0e4d3bc009bfae6abd1ef24
This regenerates the cargo lockfiles and FFI bindings header. It also revendors
the third_party/rust libraries.
MozReview-Commit-ID: ID0YhoIH6cz
--HG--
extra : rebase_source : 7c22828a831eafcf527f2c3baf8d4d012db8f9a4
Previously, the WebRenderBridgeParent for each content layer tree would use the
same WebRenderAPI instance as the top-level WebRenderBridgeParent for that window.
However, in order to make the namespacing changes work we now need to use a
separate WebRenderAPI instance for each WebRenderBridgeParent. The content
WebRenderAPIs are cloned from the parent one, so that they all share the same
backend, but can allocate resource IDs in distinct namespaces.
MozReview-Commit-ID: 7VTFL8F09n7
--HG--
extra : rebase_source : 2da1d03abc23bd7852e4b12fe133889bd80cad53
In theory the upstream API change should allow us to share the same WR renderer
instance across multiple WebRenderAPI instances. For now however I retain the
existing behaviour of one WR instance for each WebRenderAPI instance, but keep
track of the document id in a new DocumentHandle struct. The C++ side keeps
a pointer to this DocumentHandle struct instead of the raw RenderApi.
MozReview-Commit-ID: I9pCKOY1OYx
--HG--
extra : rebase_source : 7b0ae2ccb2692a76045371ac165468c7f7539b40
This patch also adds logging into ResolveJunctionPointsAndSymLinks to help diagnose issues that
might arise if the resolution fails or the path is not usable for some reason.
We hit the _adjustFocusAfterTabSwitch function in both the e10s and non-e10s cases, but through
different code paths. This makes the expected stack less specific to account for both cases.
MozReview-Commit-ID: AI4KLUNjUqZ
--HG--
extra : rebase_source : b1fd2df5231e406fe33b7cb4f778c7dc5797b08c
The preload script currently imports XPCOMUtils.jsm like so:
> Cu.import("resource:///modules/XPCOMUtils.jsm");
As explained in Bug 1383215 comments [21, 24], this has been incorrect for
years, but happened to work.
The import URL is changed so it points at the correct thing now:
> Cu.import("resource://gre/modules/XPCOMUtils.jsm");
MozReview-Commit-ID: J6j594sJs60
--HG--
extra : rebase_source : 402808439e5fba8b4909dee9a96f1e44debfa6f0
