This commit changes up the definitions of the presets a bit. I promoted the
allocations work to non-experimental, as it's fairly well supported now in the UI.
Others I demoted to experimental if they were not supported in our current UI,
or flat out don't work.
Differential Revision: https://phabricator.services.mozilla.com/D76511
This patch adjusts the profiler menu button to properly reflect the current state
of the profiler. It doesn't completely match the design spec, as there are a bunch
of CSS rules already in place in the toolbar, and I wanted to keep the changes
simple. It does however, update the UI based on the state of the profiler.
Differential Revision: https://phabricator.services.mozilla.com/D75851
This patch handles the issue where a user sends two commands two toggle the profiler and/or
capture. This gets the profiler UI in a weird state that usually is just because the UI
is hanging and lagging. This makes the profiler pause state into a "capturing" state.
I did not include a test with the behavior change, as I was worried about intermittent
failures on asserting this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D75850
This moves some symbolication code out of browser.js and into a new module symbolication.jsm.js.
It also threads the pageContext parameter through to getSymbolsFromThisBrowser so that it can
respect the correct objdir pref. This part is probably more complicated than necessary.
Differential Revision: https://phabricator.services.mozilla.com/D63914
Presets used 16Mi entries (128MiB) by default, but these numbers were a limit per process.
Now that the limit is for the whole Firefox app, we would record a lot less information, because there are typically around 8 or more processes.
So the default are now 8 times larger to roughly record a similar amount of profiling data.
Also the custom buffer maximum size has been increased from 1GiB to 2GiB.
Differential Revision: https://phabricator.services.mozilla.com/D73216
Right now trying to dump a shutdown profile from our profiler tests results in failure,
which is confusing. We should guard against this and fail the test if this happens.
Differential Revision: https://phabricator.services.mozilla.com/D74286
Display the buffer size as powers of 2, using binary-friendly units (e.g., 64MiB).
Presets have been adjusted to powers of 2.
Note that the profiler still uses this number as maximum per process, but this will change when bug 1632750 lands.
Differential Revision: https://phabricator.services.mozilla.com/D73213
This patch changes the lazy loading mechanism to explicitly create a "lazy" object
that can be used to load modules. It makes it so that TypeScript can understand what
is going on with the lazy loading. I couldn't find a solution to make the Object.define
mechanism work for the global object.
I briefly considered using the Object.define() method on the returned "lazy" object,
as this could be typed correctly, but I felt magically accessing properties was less
clear compared to calling a function that has the side effect of maybe loading a
module for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D59208
This patch takes the approach from mossop on pre-defining ChromeUtils.import
paths, so that they don't need to be defined where they are used. Perhaps in
the future we could automate this more, but for now this will make the current
approach more ergonomic for consumers of the types.
Differential Revision: https://phabricator.services.mozilla.com/D59206
This patch makes it so that the profiler shortcuts work based on the location of
the profiler menu button. It changes it so that if the menu button is in the navbar
or other menus, the shortcuts will work. Otherwise, the shortcuts will be a no-op.
This removes the Tools -> Web Developer - Enable Profiler Menu Button option. By
default on Nightly and Dev Edition the profiler menu button will be available.
On other channels, users must visit profiler.firefox.com.
Differential Revision: https://phabricator.services.mozilla.com/D66785
--HG--
extra : moz-landing-system : lando
This patch makes it so that the profiler shortcuts work based on the location of
the profiler menu button. It changes it so that if the menu button is in the navbar
or other menus, the shortcuts will work. Otherwise, the shortcuts will be a no-op.
This removes the Tools -> Web Developer - Enable Profiler Menu Button option. By
default on Nightly and Dev Edition the profiler menu button will be available.
On other channels, users must visit profiler.firefox.com.
Differential Revision: https://phabricator.services.mozilla.com/D66785
--HG--
extra : moz-landing-system : lando
about:profiling was failing to use the supported features of the target
and was instead only checking the locally supported features.
Differential Revision: https://phabricator.services.mozilla.com/D67528
--HG--
extra : moz-landing-system : lando
The feature should only be enabled if it's supported, e.g on
mobile phones.
Differential Revision: https://phabricator.services.mozilla.com/D67527
--HG--
extra : moz-landing-system : lando
The current Firefox release channel is 74, which means this old mitigation is no
longer needed. getSupportedFeatures is supported on all targets.
Differential Revision: https://phabricator.services.mozilla.com/D67526
--HG--
extra : moz-landing-system : lando
This patch makes it so that the profiler shortcuts work based on the location of
the profiler menu button. It changes it so that if the menu button is in the navbar
or other menus, the shortcuts will work. Otherwise, the shortcuts will be a no-op.
This removes the Tools -> Web Developer - Enable Profiler Menu Button option. By
default on Nightly and Dev Edition the profiler menu button will be available.
On other channels, users must visit profiler.firefox.com.
Differential Revision: https://phabricator.services.mozilla.com/D66785
--HG--
extra : moz-landing-system : lando
I originally wrote the tests to check for the "not-yet-known" recording state. This
check is a race that did not fail locally, but does when run on the try servers.
This patch makes the tests a bit more permissive. It still includes the check for
"not-yet-known", but also allows for the recording state to already be known
at the beginning of the test.
Differential Revision: https://phabricator.services.mozilla.com/D66609
--HG--
extra : moz-landing-system : lando
Platform engineers spend most of their time in Nightly and on local builds. This patch
changes it so that the profiler is most likely set to a more advanced preset when platform
engineers need it.
Differential Revision: https://phabricator.services.mozilla.com/D66407
--HG--
extra : moz-landing-system : lando
This patch does not include a test as it's a configuration change, and
should be covered by existing tests. I manually tested it on my machine
to verify that screenshots were in fact recorded.
Differential Revision: https://phabricator.services.mozilla.com/D66398
--HG--
extra : moz-landing-system : lando
Note that this patch also updates the setReactFriendlyInputValue function in
head.js, as it was not working for selects.
Differential Revision: https://phabricator.services.mozilla.com/D65151
--HG--
extra : moz-landing-system : lando
This race condition is really only exposed in automated testing, but it
was making the DevTools performance-new mochitests intermittent.
The race looks like this:
* stopProfilerAndDiscardProfiler() request
* perf actor process the request
* The gecko profiler sends an event notifying that the profiler stopped
* DevTools updates the UI upon receiving the event
* The test suite sees the UI update, and triggers a close of DevTools
* Error: Connection closed, pending request
* stopProfilerAndDiscardProfiler still hasn't sent the response yet
This patch fixes it by not throwing an error if the panel is already destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D65150
--HG--
extra : moz-landing-system : lando
The browser chrome tests previously only tested the performance-new client
from a unit testing perspective. I originally wrote them this way so that
they would be fast, and not flaky, as the client actually runs the profiler
and full browser infrastructure. However, these tests haven't been really
great at catching bugs, and the tests break pretty easy to due implementation
changes for the client.
The new browser tests have been proving fast, reliable, and great at catching
regressions. This patch moves all of the about:profiling related tests to be
exclusively mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D65149
--HG--
extra : moz-landing-system : lando
Paul Adenot
Greg Tatum
Gerald Squelart
Markus Stange
Julien Wajsberg
Alex Chronopoulos
Brindusan Cristian
Sylvestre Ledru
Daniel Varga
Ed Lee
shindli