https://github.com/servo/rust-cssparser/pull/177
Also simplify the `ParseErrorReporter` trait a bit.
Source-Repo: https://github.com/servo/servo
Source-Revision: 845131c425ebd50eea2fe5bf6005b6c304664242
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : d24cb7526225e8393bbc0a90206cba0199f95798
This will move this code to a place that will run it once per session (as needed) and not once per window. It also better defines it to run after all sessionstore-windows-restored, instead of arbitrarly after 3 seconds.
MozReview-Commit-ID: 2ekVeZfRYC4
--HG--
extra : rebase_source : 85f4e26d727a042091c5a8e5f9b9c346604d6029
Note that the DefaultBrowserCheck.prompt() was scheduled with an idle callback before and it was removed here, because it's no longer necessary (as the entire function is now running from an idle callback)
MozReview-Commit-ID: GQQbAlBn2UI
--HG--
extra : rebase_source : e317326c3dc4a47f87ba86b29dc3dbdec2657f33
This has no change in behavior since they are already scheduled with idleDispatchToMainThread, but this puts them in the proper code location
MozReview-Commit-ID: IS5ZQjJy77q
--HG--
extra : rebase_source : 08ee589ee7b88fc78dbd106c6f3f191c5fe2e928
The Browser Console interacts with a ChromeActor instance, which as any TabActor inherited actor,
expects to be "attached" by calling its `attach` request. isTabActor set to true ensures that.
While chrome set to true allows client codebase to enable additional behavior for chrome debugging.
MozReview-Commit-ID: 1MVLBKnluhg
--HG--
extra : rebase_source : 09b9cce4f6053b78cf617abbe71d54cc1b842f4e
After bug 1388569 and bug 1388572, all jobs that have needs-sccache set
have a dependency on either linux64-sccache or win64-sccache, and
vice-versa. Which means they are now redundant, and one should imply the
other.
--HG--
extra : rebase_source : ae72f67ccf2da7ba645416b8be4d10687005d01a
1. X_OK is now allowed, and is limited only by the MAY_ACCESS permission.
2. The actual access() syscall is now used, if access is granted by the
broker policy. This fixed bug 1382246, which explains the background.
MozReview-Commit-ID: 926429PlBnL
--HG--
extra : rebase_source : 6ae54c4c25e1389fa3af75b0bdf727323448294a
They just inherited the dependencies because they were using the same
tooltool manifests as compiling builds.
--HG--
extra : rebase_source : 03ee8180e455e01b72016b3132001745b87f78e7
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