We don't need to calculate TimingParams each time we compose an animation on
the compositor because TimingParams is immobile since the animation was sent to
the compositor.
MozReview-Commit-ID: 3rfzkdGClES
--HG--
extra : rebase_source : e28650a30b1cbd14789688f2acc03d204069e2fb
Etherpad has some bugs of handling non-printable key events.
https://github.com/ether/etherpad-lite/issues/3383
Unfortunately, Etherpad can be installed into any URI. So, we cannot include
all of the instances into the blacklist but we should add URIs in the list
of Etherpad:
https://github.com/ether/etherpad-lite/wiki/Sites-that-run-Etherpad-Lite
I hope that Nightly testers don't use private Etherpad or non-listed Etherpad.
MozReview-Commit-ID: HSAVwGHhW75
--HG--
extra : rebase_source : bd1e579997c773de27476630a097bda70031107f
With the strict keypress event dispatching mode, cannot navigate between
list items in keep.google.com. So, until they fix this issue, we should
include keep.google.com into the blacklist for Nightly testers.
MozReview-Commit-ID: CXNoirrgeR
--HG--
extra : rebase_source : 62af31e7bb6d8070bb57430fdbc847d5d44c0125
hangouts.google.com is used Hangouts in Gmail window. In this window, shortcut
keys are handled with keypress event for Gecko. Therefore, we need to add
hangouts.google.com into the blacklist.
MozReview-Commit-ID: 607imegrmwj
--HG--
extra : rebase_source : c17890b5fd4fed54302fc2d8ecd40b1801f37520
The decision task is used for everything built as part of a push (for
mozilla-central, this is firefox, devedition and fennec, as well as tasks that
aren't strictly part of any product). Thus, having `firefox` encoded as part of
the decision task doesn't make sense.
This changes the route from
index.gecko.v2.${repository.project}.latest.firefox.decision
to
index.gecko.v2.${repository.project}.latest.taskgraph.decision
while leaving the latter for backwards compatability with tools that expect it.
Differential Revision: https://phabricator.services.mozilla.com/D996
--HG--
extra : rebase_source : c4c4691bb4633225e5e37b21982b916f76353e27
extra : source : 6ef1607a3e63250eefbda5333d61fd338c23311d
BLEND_MODE and BLEND_CONTAINER wrap items so their bounds can change.
We need to account for that like we do with OPACTIY etc.
--HG--
extra : rebase_source : fbd2d79eaad5c7347335416d369c8cae37aad447
We previously did not require Python 3.5+ everywhere because we failed
to detect Python 3.5 on Windows in CI. That's because CI isn't using
start-shell.bat and it hasn't yet updated PATH to include
%MOZILLABUILD%\python3.
We shouldn't need to teach CI to have PATH contain everything in
MozillaBuild. This commit teaches moz.configure to automatically use
MozillaBuild's Python 3 if we're running in MozillaBuild.
Since we can now detect Python 3 everywhere in CI, we make Python 3.5+
required on all build configurations.
MozReview-Commit-ID: BwgWGeYMyPM
--HG--
extra : rebase_source : b52f604b01c73b0493b142f3f71aa26c99a42b91
npm-shrinkwrap.json got updated spuriously in pushing ec5e58165939 [1], which
should not have happened. This reverts that spurious change to go back to
sha-512 hashes.
[1] https://hg.mozilla.org/integration/mozilla-inbound/rev/ec5e58165939
--HG--
extra : amend_source : 2a21f05ff8bafd8ccd57e69acf81988455822aef
We can move this information into ProtocolState and save having two
virtual functions for every protocol. Moving some bits out of the
codegen'd IPC code is a nice bonus, though we keep the strange setup
where toplevel protocols have two mChannel member variables.
ProtocolName() is only used for producing error messages and annotating
crash reports. But examining actual crash reports that would have used
the result of ProtocolName() indicates that we can always tell what the
erroring protocol is due to the stack backtrace. So having this virtual
function around just provides duplicate information, and it takes up too
much space in the vtable besides. Let's get rid of it.
lower.py generates repetitious:
SetManager(...);
Register(...); // Or RegisterID.
SetIPCChannel(...);
calls, which are moderately sized, given that the above call sequence
requires virtual calls in several places. Instead of codegenning this
sequence, let's consolidate the sequence into IProtocol and change the
code generator to call into the consolidated function instead.
This function is only overriden in two places, both of which go away
after early beta is done. We shouldn't be paying for its vtable entry
after that point.
The reasoning here is the same as for the protocol register/lookup
functions: these functions are all basic functionality that should not
be overriden by subclasses.
This functionality is base functionality for top-level and non-toplevel
protocols; nobody overrides this stuff, so it's safe to move into
ProtocolState.
IProtocol, which is inherited by every generated IPDL protocol and every
concrete protocol implementation in-tree, has a number of virtual
methods that are only relevant when distinguishing between top-level
protocols (IToplevelProtocol) and managed protocols (everything else).
These virtual methods require pointers in every protocol's vtable, which
is wasteful, and it's also somewhat confusing that many methods exist
but don't really need to be overridable in any useful way.
Let's clean this up, by creating a ProtocolState class to hold methods
that solely differ between top-level protocols and everything else.
This commit does that work and moves Shmem-related methods into this
class as a proof that this can be done in a reasonable way.
This function is just pure bloat when it gets inlined, and it will
disappear on non-Nightly builds anyway. Make it MOZ_NEVER_INLINE so our
size statistics on Nightly are somewhat more reflective of our size
statistics on Release.
