Remove the probe, and remove the cached value check.
Also remove dead code which relies on this sometimes-clamping glGet query.
MozReview-Commit-ID: JA1VgH8fLRB
I happened to be looking at it.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8a740aa4d1e75aad9308e3eb805ed3e15078fb59
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ed8628cfef0d096dc79f96ebafced4853a805ee4
It's possible to RenderLayers for a top-level content process DocShell without that DocShell being
active. When we do this, the PresShell for that DocShell becomes active, but the DocShell stays
inactive (to avoid accidentally playing paused video or clearing notifications in that DocShell).
If a DocShell is inactive but rendering its layers, it's possible for that DocShell to navigate.
When this occurs, a new PresShell can be created, which normally reads its active state off of
the DocShell. This means that the PresShell will become inactive even though the tab is supposed
to continue rendering its layers.
This patch checks for PresShell active state when setting up a new content viewer after a navigation,
and if the previous PresShell was active, makes the new PresShell active too.
MozReview-Commit-ID: KX9HvZJKqg2
--HG--
extra : rebase_source : aac1710a64b6e5f93b9874b2a15637d94a8ce5b6
This is needed by the debugger in order to use the latest devtools-reps
package (0.19.0).
This function was already added in the devtools-connection package.
MozReview-Commit-ID: 3SVxq4Jbs16
--HG--
extra : rebase_source : a279790045eb91d96d20fca522e1b38c01d72a49
In many cases, building docker images starts on machines that don't have
a cached checkout, and it often takes forever to get a full clone. It
used to be worsened when 3 jobs could run at the same time because the
worker would start up clean, and 3 jobs would be doing a mercurial clone
at the same time, thrashing I/O, but that part is fortunately fixed.
It is still, however, appreciable not to waste time in the mercurial
clone part of image creation.
--HG--
extra : rebase_source : 8c76bc91e1d5102f68c43e1050d61971fef32e9f
The image builder image we use to build docker images is updated
manually, and not necessarily when changes occur in tree that should be
reflected by a new image builder image. For instance, its run-task is
currently outdated. Not enough that it's actually a problem, but it
could rapidly become a problem.
There is also a lot of friction when trying to make changes in how
docker images are built, and while last time I tried, I ended up not
being able to do the changes I wanted to make because the docker version
on the host is too old, but this is already the second time I've been
trying to make things better and hit a wall because the the image
builder is essentially fixed in stone on the docker hub.
So with this change, we make all the docker images use the in-tree image
builder image, except itself, obviously. That one uses the last version
that was uploaded. We may want to update it at some point, but not doing
so will only impact building the image builder image itself, not the
other ones.
--HG--
extra : rebase_source : 978cf033732cbbbb277d206dec69660175b82afa
And remove the two cases that currently set that, without actually using
it. The webrtc gtest one never relied on it, and the gfx one was added
in bug 1427668 for a single header, and the corresponding #includes were
changed in bug 1428678.
--HG--
extra : rebase_source : ebb3aed6ff8e3438d4a2f011725cf1a15986fee6
Only animationcancel event uses current time, the elapsed time for other
animation events are simply calculated from given animation properties (e.g.
animation-duration, animation-delay, etc.), so they should not be reduced the
precision.
See the table for each elapsed time;
https://drafts.csswg.org/css-animations-2/#event-dispatch
MozReview-Commit-ID: 1KGUAdDHyXV
--HG--
extra : rebase_source : 8bc803ff9e3526396e694082392f9d1454999a0f
It was neglected to mark navigator.credentials as [SecureContext], yet it
must be for spec compliance and powerful-features compliance.
MozReview-Commit-ID: BYKGqqhoS2L
--HG--
extra : rebase_source : 441be2ae91d51cfff1ed5a8d1e96db4f9a3c917c
Back in bug 1360609, we added `run-on-projects` to a list so that the
toolchain tasks wouldn't run on every push on release branches.
Fast forward to now, and they're depended upon by other tasks, meaning
they are triggered when appropriate, without resorting to that trick. In
fact, the commit message for bug 1360609 said we could switch to an
empty list once the jobs have dependencies.
The same is true from package tasks, which, in fact, I suspect would
happen on every push on release branches.
The only exception is for a few toolchains that are depended upon by
nothing, and that are produced for developer consumption with e.g. mach
artifact toolchain.
--HG--
extra : rebase_source : bb8624fed7490b85f4bd72b7ceb2db7a72b4c2ab
Since it was removed from gecko, and this confuses a lot to
ports/geckolib/tests/build.rs.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1f6a864ab5372fe4f59b1a4c3db7cf8e7a79b06d
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 16f690c5b5e3af8dfe2fb7207496a196c5875032
