The build system's TestResolver does a pretty good job of getting the right manifestparser
based tests to run, but it isn't perfect. Notably, it ignores the 'disabled' key. We filter
the tests through manifestparser here to make sure the build system didn't miss anything.
For context, this is also what the other test harnesses (e.g mochitest) do as well.
MozReview-Commit-ID: FaHb4nvuoK9
This deprecates PYTHON_UNIT_TESTS and replaces it with PYTHON_UNITTEST_MANIFESTS.
In the build system, this means python unittests will be treated the same as all
other test suites that use manifestparser. New manifests called 'python.ini' have
been created for all test directories containing python unittests.
MozReview-Commit-ID: IBHG7Thif2D
The mozbase unittests don't use mozunit, so their output is confusing in the log.
This makes mozbase output consistent with the rest of the python unittests.
MozReview-Commit-ID: AIs5mza8Rn6
The mozsystemmonitor test is under mozsystemmonitor/mozsystemmonitor/test instead of
mozsystemmonitor/tests like all the other mozbase modules.
MozReview-Commit-ID: AIs5mza8Rn6
This removes gaia_desktop, gaia_emulator, marionette_emulator,
webapi_desktop, and webapi_emulator test suite definitions.
MozReview-Commit-ID: Lf8slbzKNLz
moz.build achieves better results than Gradle, and I can't fully
explain why that is. At first I thought it was due to
-optimizationpasses, which is 6 for MOZILLA_OFFICIAL; however, it's
not -- I see no change (let alone an improvement), when I set the
number of passes to 1, 6, 10, or 100. I think there are two things at
play. First, moz.build strips debugging information from "libraries",
which are broadly the Google support libraries. I don't think it's
possible to strip debug information in this fine-grained manner using
Gradle. Second, I think the Gradle build might be including more code
than the moz.build configuration (see the follow-up patch removing
multidex support), but I can't determine what's actually different.
After APK compression, I see less than a 50kb regression in APK size
between Gradle and moz.build outputs, which I deem reasonable.
MozReview-Commit-ID: 4q4Zye2wnOF
taskcluster-scheduler is deprecated. mozharness uses it to get the task
graph in order to discover the parent of a task.
We now use queue to get the task definition, which contains the
'requires' field.
MozReview-Commit-ID: 8IivfxLvxVA
While we don't have physical machines running taskcluster-worker, we
want to schedule talos tests on Taskcluster and run them on buildbot.
buildbot-bridge acts as a worker that runs its tasks in buildbot
machines. Any talos task is redirected to buildbot-bridge.
MozReview-Commit-ID: Im9IhhT0Mr1
This major version of kinto.js released without a FirefoxStorage
adapter. Since Gecko is the only project with a need for this adapter
as well as the only one who can use it, that file moves to this repo
as a new kinto-storage-adapter.js. This file is mostly a copy of the
most recent FirefoxStorage.js, plus some other non-exported utility
functions copied from kinto.js to make it work.
This changes the export of the kinto-offline-client.js from a
`loadKinto` function which returns the Kinto class, to the actual
Kinto class itself, with the user expected to "hook up" the
adapter. It turns out that this doesn't change much in how we actually
use Kinto, since we were always previously explicitly selecting the
Kinto adapter.
This release of kinto.js also changes some of the build options
around, which changes the minified output of kinto-offline-client.js.
There are still some outstanding stylistic complaints about
FirefoxAdapter having to do with its _init static method which is
public and the fact that sometimes FirefoxAdapter manages its own
Sqlite connection and sometimes it doesn't. These will be addressed in
a future patch.
MozReview-Commit-ID: HF0oNCEDcFs
Creating ImageBitmap from the following sources includes allocating new memory:
(1) from ImageData.
(2) from Blob.
(3) from HTMLCanvasElement.
(4) from CanvasRenderingContext2D.
(5) from Structured-clone.
(6) from Transferring.
(7) from OffscreenCanvas.
(8) from ArrayBuffer/TypedArray.
We need to report to DOM so that the GC would be triggered appropriately.
MozReview-Commit-ID: 7rvNsjVNqpz
I talked to mstange about this, and what might be happening here is that there's
a difference in rounding going on during (I think) rasterization. The change is
very small and not human-noticable, so I think taking this fuzzyness is worth
the cost considering the gain in functionality.
MozReview-Commit-ID: C0CPNrIdCDu
Earlier patches in this series add SVG icons for unstyled checkboxes and radio buttons.
This causes us to queue extra loads to documents that have those elements, even when
we're natively styling those input elements by default.
browser_toolbox_options works by loading up the DevTools options iframe, and then
clicking on things to make sure that the right prefs are set. There are checkboxes
in the iframe document, which means the extra loads I referred to happen. When
our presentation subsystems notice that there are extra loads occurring, we do
"paint suppression" to avoid flashes of unstyled content. During paint suppression,
nothing is displayed (painting is suppressed), and so nothing is clickable.
browser_toolbox_options was not waiting for the "load" event before clicking on
items. It got lucky up until the SVGs were added, but this was a race waiting
to happen. I've added a wait for the "load" event, and this test now passes.
MozReview-Commit-ID: EjzvhxhKlDs
<input>'s of type checkbox and radio are rendered as native widgets by default
on Desktop, but on Fennec, we fallback to using the built-in, non-native
checkboxes.
The earlier patches in this series made it possible for agent, user and page
stylesheets to make changes to the non-native checkbox and radio input fields.
Unfortunately, some of the default agent styles for those checkbox and radio
elements on Fennec were accidentally setting rules that they shouldn't. That
wasn't a problem before because the inputs couldn't be styled before. Now that
they can, we're failing a bunch of reftests because the inputs look wrong in
certain situations.
For example:
1) We were setting background: var(--form_background) for every radio and
checkbox input. --form_background is just a colour though, and that meant
that the rest of the background styles were being overwritten. This has
been fixed by setting background-color: var(--form_background) instead.
The same also applied to some usage of --form_background_disabled.
2) We were setting border-radius: var(--form_border_radius) on all input
elements, but this was putting rounded corners on the checkbox and
radio inputs as well. This rule has been modified to skip checkbox
and radio inputs.
MozReview-Commit-ID: CnpTRXcCxoY
