This introduces a new toolkit module, ContentDOMReference, which can generate identifiers
for DOM elements that can be safely passed across the process boundary without having to
use the CPOW infrastructure.
The Password Manager code seemed to be the only thing using the original CPOW, so this
has been updated to use the ContentDOMReference identifier instead.
Differential Revision: https://phabricator.services.mozilla.com/D32758
--HG--
extra : moz-landing-system : lando
Do not include the problematic manifest on Android. We never run Android
mochitest-browser-chrome anyway. Bug 1435429 used a similar approach.
Differential Revision: https://phabricator.services.mozilla.com/D34011
--HG--
extra : moz-landing-system : lando
In bug 1538508 we changed the MediaChangeMonitor to raise an error when we try
to create a decoder and we don't yet have the H.264 extra data, to maintain the
assumptions made by OpenH264/WebRTC. This however doesn't play nice with the
HLS demuxer, which won't always give you extra data after a seek.
So change the MediaChangeMonitor to by default assume that it should just drop
frames until it has the extra data it needs to create a decoder. We can flag
this mode off in the WebRTC MediaDataDecoder.
Differential Revision: https://phabricator.services.mozilla.com/D34079
--HG--
extra : moz-landing-system : lando
Not only animating transform-like properties, but also non-animating ones have
to be passed into the compositor, so the final transform matrix could
take them into account (on the compositor).
Differential Revision: https://phabricator.services.mozilla.com/D33580
--HG--
extra : moz-landing-system : lando
So we can use StaticPrefs::layout_css_individual_transform_enabled() in
the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D33579
--HG--
extra : moz-landing-system : lando
mozharness and mozharness test transforms for generic-worker currently
don't wrap the commands with run-task. This changes things such that the
commands are wrapped with run-task, by piggy-backing on the run_task
transform.
Some things then become redundant with what the run_task transform does,
and some others need to happen later than they currently do in order to
work.
Depends on D28026
Differential Revision: https://phabricator.services.mozilla.com/D28027
--HG--
extra : moz-landing-system : lando
mozharness and mozharness test transforms currently do their own version
of wrapping commands with run-task in docker-worker. This makes them
piggy back on the run_task transform instead.
Some things then become redundant with what the run_task transform does,
and some others need to happen later than they currently do in order to
work.
This has the side effect of enabling some of the more recent run-task
features, like --fetch-hgfingerprint.
Depends on D28025
Differential Revision: https://phabricator.services.mozilla.com/D28026
--HG--
extra : moz-landing-system : lando
The tasks on bitbar currently rely on being run as root, and run-task
defaults to drop its privileges to the `worker` user.
Depends on D28024
Differential Revision: https://phabricator.services.mozilla.com/D28025
--HG--
extra : moz-landing-system : lando
The macos workers have two python 2.7 installed: one in /usr/bin, and
one in /usr/local/bin. For some reason, the one in /usr/local/bin is
broken wrt SSL.
When running the current mozharness command directly without a full path
to python2.7, generic-worker executes it using its own PATH, and that
uses /usr/bin/python2.7. When wrapping with something else, though
(run-task, but that would apply just as much with `sh -c`), the PATH
from the task itself is used, and it's explicitly set to use
/usr/local/bin first, and the broken python 2.7 then gets used.
We could change the PATH, but there might be other things relying on the
current order, so just use /usr/bin/python2.7.
Depends on D28023
Differential Revision: https://phabricator.services.mozilla.com/D28024
--HG--
extra : moz-landing-system : lando
Follow-up to [Bug 1093953](https://bugzilla.mozilla.org/show_bug.cgi?id=1093953) which introduced a generalized `payload` object for messages to be populated asynchronously with additional data associated with the message after it is initially received.
The reasoning is: messages can have arbitrary data payload associated with them. The rendering component for the message type will consume and validate that payload data.
Here, we replace the specialized messageTableDataByID with the generalized messagePayloadByID, update corresponding Redux actions, reducers, selectors and tests.
The only place where `tableData` is used is in the `ConsoleApiCall` message type, in the `ConsoleTable` component. We replace it with `payload` which is sent down to all message types anyway.
Differential Revision: https://phabricator.services.mozilla.com/D33975
--HG--
extra : moz-landing-system : lando
This patch includes the response status and response text for the abuse report submission failures in the AbuseReportError message, to make it easier to investigate report submission errors.
Differential Revision: https://phabricator.services.mozilla.com/D32812
--HG--
extra : moz-landing-system : lando
Used custom logger for testing.raptor.raptor files to mention log level in messages
Differential Revision: https://phabricator.services.mozilla.com/D32985
--HG--
extra : moz-landing-system : lando
The new RaptorLogger class will add prefixes to raptor logging messages.
These changes will help raptor to display the log messages with the right log_level.
Differential Revision: https://phabricator.services.mozilla.com/D32984
--HG--
extra : moz-landing-system : lando
RaptorErrorList now includes HarnessErrorList and regular expressions for Error and Critical log levels.
Differential Revision: https://phabricator.services.mozilla.com/D32983
--HG--
extra : moz-landing-system : lando