We used to clear a timeout in HTMLTooltip which is supposed to resolve a Promise
when it's executed, meaning that we could end up with Promises that would never
resolve.
In the test itself, we wait for a tick between each loop iteration and after hiding
the popup to make sure everything has the time to be painted.
Differential Revision: https://phabricator.services.mozilla.com/D83912
The profiler can be "paused", which stops sampling, and since bug 1578329 stops markers as well.
Some test suites use pausing between tests (to better differentiate the tests, to keep the profiler ready to run, and to lower the amount of recorded data). But this causes problems with some tracing markers, as their matching ends have not been recorded (e.g., an end marker is missing), which show up as very loooong markers.
To solve this, we need to be able to pause sampling only, but keep recording markers.
But we still need to be able to pause the whole profiler, in particular before capturing, to avoid recording anything around that time.
This big patch is mostly mechanical changes: Wherever there are "Pause" and "Unpause/Resume" profiler functions, we add matching "PauseSampling" and "UnpauseSampling/ResumeSampling" functions that only impact the periodic sampling loop; And existing "Pause/Unpause/Resume" imply pausing sampling as well.
Exceptions and extra work:
- nsIProfiler (the JS API) already had `Pause/ResumeSampling()`, which misleadingly paused everything! Now they do the right thing, and we have `Pause/Resume()` as well.
- All tests using `Pause/ResumeSampling()` now use `Pause/Resume()`, except for Talos tests that only pause sampling between tests; Added some extra `Pause()` calls to pause everything before capturing profiles.
- GeckoJavaSampler doesn't handle pausing/resuming everything, this should be done in a follow-up bug.
- Sampling-only pauses are not streamed into JSON. If needed, we should follow-up, with potential work on the front-end to deal with these.
Differential Revision: https://phabricator.services.mozilla.com/D81492
This is a brand new (and first) DAMP talos test for accessibility panel. "accessibility.cold-open" is similar to other cold open tests such as inspector one. It opens accessibility panel, waits for its UI to render and then closes the toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D80512
Talos tests suffer the most from intermittents that seem due to the Base Profiler.
So until symptoms are reduced (bug 1648324) or the root cause is fixed (bug 1648325), Talos tests will run without the Base Profiler.
Differential Revision: https://phabricator.services.mozilla.com/D81019
The complicated test loads a lot of iframes. Now that with my changes we
coalesce stylesheet loads across documents it's expected to have way
less network loads for this test, which has a lot of facebook iframes
that load multiple stylesheets each.
The value is the one that made it reliably pass on my machine.
Differential Revision: https://phabricator.services.mozilla.com/D79394
DAMP refreshes the page that it loads, and it bypasses the caches, but
we still coalesce in-progress loads, so it's expected to see less of
this.
This actually caught another issue, that I'm fixing in bug 1645180.
Differential Revision: https://phabricator.services.mozilla.com/D79352
DAMP refreshes the page that it loads, but doesn't clear the stylesheet
cache, so the second+ time around some of the zoom messages will not be
sent.
This is actually a wider issue, that I plan to fix in bug 1645180.
Meanwhile don't wait for these messages.
Differential Revision: https://phabricator.services.mozilla.com/D79352
`attr-selector-1.html` currently takes 89 seconds on my machine. That's quite an outlier when its sibling tests are in the few-tenths to few-seconds range.
Because these tests are run for PGO, I'm concerned about a risk of overtraining. The #1 function in our profile, related to the attrs test, has 1200M counts, while more typical values for our hottest functions are in the 200M range. This might make functions lower on the list seem colder than they really are.
Differential Revision: https://phabricator.services.mozilla.com/D77899
I need to add symbolication support for the mochitest Gecko Profiler command line
option. These profiles also need to be symbolicated. Unfortunately, there is not
a common place where I could use these files. Talos and Raptor each had their
own copy of the snappy symbolication server.
This commit consolidates these packages into a re-usable mozbase package that can
be used in mochitests, and eventually in other places like xpcshell tests.
I stubbed out a test file, but it doesn't do anything quite yet. This commit makes
it so that the tests still work in Raptor and Talos, but doesn't add any features.
It also doesn't try too hard to make the files look like a mozbase package.
Differential Revision: https://phabricator.services.mozilla.com/D74289
The current implementation opens the built Firefox in the objdir. This is not
optimal as the built Firefox is not really great for viewing files in. The build
could be broken. With this patch, the profiles will instead be opened in the users
default browser.
Differential Revision: https://phabricator.services.mozilla.com/D70089
Inspecting a node with many CSS variables makes the Rules view render slowly. A patch to improve performance is in development in D73062.
This patch adds a new subtest, `custom.inspector.manycssvariables.selectnode`, to the existing custom Inspector DAMP test to measure the rendering time for a node with 300 CSS variables all of them used (600 declarations in total).
It might seem extreme. In May 2020 youtube.com has 1,375 CSS variables applicable to the `<html>` element. They all get inherited by all CSS rules for most nodes on the page. This slows down the action of inspecting CSS for any node. The largest CSS rule from youtube's stylesheets has 287 declarations of CSS variables. In the age of automatically-generated stylesheets for design systems this scenario becomes more common.
Differential Revision: https://phabricator.services.mozilla.com/D73289
This patch use the new `exception` and `hasException` field from nsIScriptError
so we can render the actual object in the message error instead of a stringified
version.
Error object are still displayed using the `customFormat` prop, so we display
only the type + message + stacktrace (but we'll have a way to inspect them
in the sidebar soon).
Existing tests were updated to fix failures, and some tests/test cases were
added to make sure we cover all the different kind of errors we can display
in the console.
Differential Revision: https://phabricator.services.mozilla.com/D71288
