This is especially useful when debugging both Base Profiler and Gecko Profiler,
so that their messages are correctly sequenced.
Differential Revision: https://phabricator.services.mozilla.com/D54447
--HG--
extra : moz-landing-system : lando
In practice the previous test that was deleting Base Profiler data when the
index became greater that 1 was correct for Firefox, because the Base Profiler
*always* starts before the very first Gecko Profiler active instance.
However in tests (like the one in the following patch) this may not be true,
because each test may start and stop the profiler, and the recent storage update
means that the index doesn't go back to 1. So when a test (apart from the first
test to use the profiler) attemps to use the Base Profiler, that Base Profiler
data will be immediately discarded because the index is already greater than 1
(from previous tests).
This change is more future-proof as well, in case we later want to use the Base
Profiler more than once in a Firefox instance.
Differential Revision: https://phabricator.services.mozilla.com/D54445
--HG--
extra : moz-landing-system : lando
The Base Profiler originally named the main thread "Main Thread", which is
friendlier than "GeckoMain". However this makes it more difficult to combine the
controls for both profilers if they use different names.
So now both profilers use "GeckoMain", so filters can be exactly the same.
Base Profiler adds "(pre-xul)" to the name to distinguish tracks in the
frontend -- This distinction is actually necessary so the frontend doesn't get
confused by threads with the exact same name, but eventually tracks will get
combined in the frontend as well.
Differential Revision: https://phabricator.services.mozilla.com/D54444
--HG--
extra : moz-landing-system : lando
This ensures that no more Base Profiler (BP) activity can happen when Gecko
Profiler (GP) starts.
In particular on Linux this is needed because the BP sampler sends signals to
stop threads, and the just-starting GP could receive this signal before it is
fully ready to handle it with its own sampler.
Differential Revision: https://phabricator.services.mozilla.com/D54443
--HG--
extra : moz-landing-system : lando
JSON profiles from the Base Profiler were assumed to be empty if they contained
zero characters, but in fact they contain one character (a single newline).
Differential Revision: https://phabricator.services.mozilla.com/D54442
--HG--
extra : moz-landing-system : lando
If we are dealing with a markdown file with a front matter,
we read the information from the front matter/YAML,
write a new md file with the right information
and copy it in the target directory
Depends on D54426
Differential Revision: https://phabricator.services.mozilla.com/D54427
--HG--
extra : moz-landing-system : lando
The `onEngagement` task fails on beta due to how the mock extension is created with `useAddonManager: "temporary"`, which prevents the extension from being able to use `browser.urlbar`. That's the only task in the file that does that. I think I copied it from another test file. Not sure why I just didn't use the pattern in this file.
This also removes `incognitoOverride: "spanning"`. It's not necessary and none of the other tasks do that either.
Differential Revision: https://phabricator.services.mozilla.com/D54795
--HG--
extra : moz-landing-system : lando
People do like to use zoom along with transforms for legit reasons, which means
that we get this wrong.
This is unfortunate, as the whole point of the hack was fixing sites that only
used zoom without regressing sites that would do:
zoom: 0.5;
-moz-transform: scale(0.5);
transform-origin: 0 0;
So we're a bit stuck here. The only way to deal with the known regressions is
parsing `zoom: 1` as invalid, which is insane, and it would probably cause other
compat issues... For now disable the pref.
Differential Revision: https://phabricator.services.mozilla.com/D54685
--HG--
extra : moz-landing-system : lando
Our detour cannot handle assembly patterns which is injected by the code coverage
instrumentation. We need to skip them in CCov build.
Differential Revision: https://phabricator.services.mozilla.com/D54745
--HG--
extra : moz-landing-system : lando
Bulk memory reduces active segments to sequences of *.init that are executed
before the start function is called. This implies that an error here is to be
reported as a RuntimeError, as an error in the start function would. The latest
spec tests for bulk-memory check this, so we're required to update as well.
Differential Revision: https://phabricator.services.mozilla.com/D54598
--HG--
extra : moz-landing-system : lando
When fuzzing, return an error instead of crashing in PrincipalInfoToPrincipal() for some error cases.
Differential Revision: https://phabricator.services.mozilla.com/D54215
--HG--
extra : moz-landing-system : lando
Whereas:
- desktop tests don't make this check;
- the check for directory existence has been troublesome and almost never useful;
- bug classification of this condition has been troublesome;
- if a startup crash actually did occur before crashreporter init, there would still be an indication in logcat and possibly a tombstone, and the "No test summary found" check would definitely be triggered;
Let's stop checking for minidumps directory creation.
Differential Revision: https://phabricator.services.mozilla.com/D54755
--HG--
extra : moz-landing-system : lando
