We use autograph-prod for our ci, nightly, and release signing. Autograph-stage doesn't have the same guarantees for availability, so pointing, say, dep-signing at autograph-stage would have resulted in occasional tree closures whenever autograph-stage changes configuration or is down.
However, we also want a way to verify autograph-stage is still valid, after the autograph team makes changes. This task is meant to be add-task'ed; a green result means autograph-stage has signed the mar file correctly.
Differential Revision: https://phabricator.services.mozilla.com/D20749
--HG--
extra : moz-landing-system : lando
They appear to be causing tasks to take several hours to complete.
Differential Revision: https://phabricator.services.mozilla.com/D21775
--HG--
extra : rebase_source : a55cfc24527662427bbeccf0d03f97dca047a3cb
extra : amend_source : 5e352a1ff382353460fdd143d7d0ba52251a5b8a
This doesn't matter yet because all the states that return a change hint are on
stylesheets, but will matter with bug 1472637.
Differential Revision: https://phabricator.services.mozilla.com/D21616
--HG--
extra : moz-landing-system : lando
Currently, PresShell::EventHandler::HandleEvent() sets `overrideClickTarget`
only when Pointer Events is enabled and there is pointer capturing content,
and this is computed while dispatching a pointer event.
So, if we move it into EventTargetData, we can move the pointer event
dispatching block into a separated method and caller can receive it with
an EventTargetData instance which is anyway necessary to receive new
target frame after dispatching a pointer event.
Differential Revision: https://phabricator.services.mozilla.com/D21190
--HG--
extra : moz-landing-system : lando
The test uses some custom code to wait for the new window, probably just
because the test is old. The fix is to use the BrowserUtils method instead.
Differential Revision: https://phabricator.services.mozilla.com/D18478
--HG--
extra : moz-landing-system : lando
We restrict the argument (i.e. `nsCSSPropertyIDSet`) of some functions is
the subset of other property set (e.g. transform-like properties), so
add this function for better readability.
Depends on D19629
Differential Revision: https://phabricator.services.mozilla.com/D21598
--HG--
extra : moz-landing-system : lando
Transform display item may have multiple properties, so it's better to
use display item type as the input.
Also, factor some code out of AddAnimationsForProperty, so we can easier
to extend this for multiple properties.
We will pass a list of layers::Animation to the compositor thread. In
this list, the animations belonging to the same property are grouped together,
so we can easily separate the animations by property and sample the animations
for each property on the compositor thread. (Will do this in Bug 1425837.)
Depends on D19628
Differential Revision: https://phabricator.services.mozilla.com/D19629
--HG--
extra : moz-landing-system : lando
We use DisplayItemType as the input of HasAnimationsForCompositor, and
nsCSSPropertyIDSet as the input of GetAnimationsForCompositor.
The caller of HasAnimationsForCompositor just wants to check if there is
any compositor animation for a display item, so we can replace it by the
display item, and get the properties from this display item.
However, the caller of GetAnimationsForCompositor may use a subset of
transform-like properties for getting scale factors, or use all the
transform-like properties for sending all transform animations to the
compositor thread.
Depends on D19630
Differential Revision: https://phabricator.services.mozilla.com/D19628
--HG--
extra : moz-landing-system : lando
FrameLayerBuilder needs to clear this flag by DisplayItemType, so we add
a new function for it.
Differential Revision: https://phabricator.services.mozilla.com/D19630
--HG--
extra : moz-landing-system : lando
Fennec has a value of OMNIJAR_NAME that contains a directory, contrary
to other platforms, and relies in post-packaging, pre-unpacking steps to
accommodate with the difference.
With this change, we just make the packaging and unpacking steps aware
of this setup, and make allow them to pack/unpack resources in foo/
under foo/$OMNIJAR_NAME, whether $OMNIJAR_NAME is a file name or a path.
This will, further down the road, allow the packager code to handle jar
logs from PGO instrumentation without munging them.
Differential Revision: https://phabricator.services.mozilla.com/D21654
--HG--
extra : moz-landing-system : lando
There are at least two known side effects of initializing it after
loading libxul:
- We can't set LLVM_PROFILE_FILE for the instrumentation part of PGO to
make the compiler-rt static initializer pick it.
- We can't set MOZ_DEBUG_LINKER to enable the linker debug log (which
used to work when environment variables were set earlier).
Differential Revision: https://phabricator.services.mozilla.com/D21646
--HG--
extra : moz-landing-system : lando
WebM specify that timestamp must be monotonically increasing. Unfortunately, this is not always the case.
WebM doesn't have a concept of frame duration, the duration is calculated as being the delta between the next frame's time and the current one. So non-monotonically increasing timestamps would have caused negative duration.
Differential Revision: https://phabricator.services.mozilla.com/D21687
--HG--
extra : moz-landing-system : lando
It doesn't need a high precision performance.now() to count minutes. In addition, if there are no windows to be closed, it's not doing anything, so it doesn't need to open a new one.
Differential Revision: https://phabricator.services.mozilla.com/D21083
--HG--
extra : moz-landing-system : lando
