This patch extends raptor to support running performance tests on chromium-as-release
for android (cstm-car-m).
At the moment we will only run on priority benchmark tests (e.g. speedometer)
Differential Revision: https://phabricator.services.mozilla.com/D190579
Chromium-as-Release (CaR) is a custom upstream chromium build (configured as "release")
On the desktop platform we have these builds running already.
This patch adds support for custom-car Android builds to be useable in performance testing.
Since android tests are run on a linux host, we make use of the existing chromium linux chromedriver fetch.
At the moment we only want the performance tests to run on speedometer.
Differential Revision: https://phabricator.services.mozilla.com/D191212
This patch adds the ability to build custom chromium-as-release (CaR) for the android platform (arm64).
A linux host is used for the android builds so a new dockerfile is added to maintain as either platform (e.g. Linux and Android) may
have differing dependencies and potentially diverge further in the future.
We can look into consolidating them into one dockerfile later if needed.
Differential Revision: https://phabricator.services.mozilla.com/D189604
Add an --expected-failures option to `mach wpt-inerop-score`. This
takes the path to a file which has the format:
\# Mark entire test as expected failure
/test/id.html
\# Mark one subtest as expected failure
/another/test/id.html,subtest name
The output is the actual interop score, plus two extra columns, one
giving the fraction of the score accounted for by expected failures,
and one giving the score after accounting for expected failures.
Differential Revision: https://phabricator.services.mozilla.com/D188729
These 3 tests handle the profiler events themselves instead of using the
TalosParentProfiler or TalosContentProfiler that already do this. But these
tests were only adding an "instant" marker at the end of the subtest.
This patch changes these "instant" markers into "duration" markers by providing
a `startTime` argument in their options object. If `startTime` is provided they
are already considered a duration marker by adding the `endTime` as
`performance.now()`.
This patch also changes the arguments that are passed inside the
`ChromeUtils.addProfilerMarker` calls. This makes the markers a lot better in
the profiler UI by grouping them inside a single row instead of showing them
individually, and allocating a lot more space in the viewport.
Differential Revision: https://phabricator.services.mozilla.com/D191358
The marker strings in the `subtestEnd` calls will show up in the profiles as
markers. But they will show up as a duration marker that starts when the
subtest starts and ends when the subtest ends. That's why naming them as "test
end" doesn't make sense. They are both the start and end.
Differential Revision: https://phabricator.services.mozilla.com/D191357
Previously we were pausing the profiler right after starting it. Then we were
resuming it right before each subtest. Then at the end of the subtest were
pausing it again. I believe this was done to make the testing areas visible.
But we now have profiler markers to show the testing duration/times instead of
pausing and resuming the profiler all the time. It doesn't add value to
pause/resume it, instead it actually loses some information like GC that
happens right after the test.
So instead of pausing and resuming the profiler all the time, this patch
removes this logic completely. We don't really need to pause the profiler
between the tests at all. This will also fix the issues like Bug 1838824, where
the profile data is completely empty because we fail to pause/resume the tests
where they handle the test measurements themselves.
Differential Revision: https://phabricator.services.mozilla.com/D191356
AFAICT the browser-addons.js code is unused.
The AM code is untested, at best, but probably unused after the demise of the disco pane.
Either way, using browsingContexts to determine the toplevel browser seems better and is
easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D191425
Don't render the whole React app in a main tab, instead move the
main element to wrap the editor.
Don't use a list for rendering the secondary panels, but <aside> elements,
so they can be access through landmark navigation.
Make the different article labelled by the h2 we already have there.
Differential Revision: https://phabricator.services.mozilla.com/D190446
The TTL refresh is done asynchronously with low priority on windows.
When clearing the cache between tests, this callback may still exist
so it may refresh the cache entry with the native value instead of the TRR one.
Differential Revision: https://phabricator.services.mozilla.com/D191399
The frame elements already had the correct roles assigned,
but this was made completely useless because we had a
`display: contents` on them, which strips any accessibility role.
This was done for layout purpose that we now can do with
subgrids, so we update the component's CSS.
We also update the markup so copying stacktrace still works as expected.
A webconsole test is added to ensure those stactkrace frames
can be navigated with the keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D190594
In `getTokenLocation`, the call to `coordsChar` needed an extra parameter so the
coordinates are relative to the top left corner fo the currently visible window.
We were passing the center of the bounding client rect to `getTokenLocation`, but
a token could wrap and have it's bounding rect center not being on the token.
To fix this we're passing the center of the first box quads of the token.
The inline preview widgets were causing some troubles on CodeMirror internal
state too. Since we're using React to populate the bookmark we set on the line,
and given that React.render is asynchronous, we were setting an empty element
as a bookmark on the editor, which React populates later. But CodeMirror probably
update its internal state when the bookmark is added, so that was causing wrong
computation later.
To avoid that, we only set the bookmark once React actually rendered the element
in the DOM.
Finally, while codeMirror already listen for window resize to update its internal
state, the Editor can be resized without the window being resized,
when primary/secondary panels are resized. In such case, we manually trigger
a codeMirror refresh.
We add a test to cover this, and also modify test helpers so we would query
the DOM instead of relying on CodeMirror methods.
Differential Revision: https://phabricator.services.mozilla.com/D190272
