When the launcher process is enabled, the firefox.exe process that we want to
track for main thread I/O isn't the first firefox process that started, but
rather the second firefox.exe process, i.e. the first child process of the first
firefox.exe process.
Depends on D4970
Differential Revision: https://phabricator.services.mozilla.com/D4971
--HG--
extra : moz-landing-system : lando
The launcher process needs a couple of flags to work correctly under talos.
This patch sets those flags.
Differential Revision: https://phabricator.services.mozilla.com/D4970
--HG--
extra : moz-landing-system : lando
Summary:
When switching to async, it is important to catch exception or register a rejection handler
so that errors keep being logged.
So in this patch I'm catching exception in a couple of important codepath.
Depends On D4541
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D4542
MozReview-Commit-ID: IDPJVkAPbTs
Summary:
When switching to async, it is important to catch exception or register a rejection handler
so that errors keep being logged.
So in this patch I'm catching exception in a couple of important codepath.
Depends On D4541
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D4542
MozReview-Commit-ID: IDPJVkAPbTs
Here we are simulating a user typing a few letters in
the console input, when the console output has 500 messages.
We wait between each 'keystroke' in order to have a
realistic measure. Also, we are typing a string that is
triggering the popup as it also impacts typing performance.
Differential Revision: https://phabricator.services.mozilla.com/D4658
--HG--
extra : moz-landing-system : lando
The aushelper add-on is no longer needed and needs to be removed before bootstrapping for add-ons is removed
Depends on D5918
Differential Revision: https://phabricator.services.mozilla.com/D5919
--HG--
extra : moz-landing-system : lando
The aushelper add-on is no longer needed and needs to be removed before bootstraping for add-ons is removed
Depends on D5338
Differential Revision: https://phabricator.services.mozilla.com/D5339
--HG--
extra : moz-landing-system : lando
Most of the changed lines in the patch are a result of moving resources
from this extension from chrome: to resource: URLs. The more significant
change lurking behind that one is that the webextension api.js file is
loaded asynchronously so it does not run as early in startup as bootstrap.js
used to run. This causes races for some of the users of talos powers,
these are addressed by adding a simple ping-pong exchange that talos powers
consumers can use to ensure that the extension is fully initialized before
trying to use its features.
Differential Revision: https://phabricator.services.mozilla.com/D6870
--HG--
rename : testing/talos/talos/talos-powers/bootstrap.js => testing/talos/talos/talos-powers/api.js
rename : testing/talos/talos/talos-powers/install.rdf => testing/talos/talos/talos-powers/manifest.json
extra : rebase_source : 30fc6ca067d34f9a3bb4d311a708ab17718a14b5
This is more than just a simple packaging conversion, this patch also
rips out the usage of nsICommandLineHandler. A side effect of that
change is that it became much trickier for the extension to tell if it
should be active or not, that is addressed by having the test harness
explicitly set an environment variable rather than inferring from the
command line arguments what should happen.
Differential Revision: https://phabricator.services.mozilla.com/D6869
--HG--
rename : testing/talos/talos/pageloader/bootstrap.js => testing/talos/talos/pageloader/api.js
rename : testing/talos/talos/pageloader/install.rdf => testing/talos/talos/pageloader/manifest.json
extra : rebase_source : 2163ddc1c00640ca65d2508336052181ee5c2b22
When the launcher process is enabled, the firefox.exe process that we want to
track for main thread I/O isn't the first firefox process that started, but
rather the second firefox.exe process, i.e. the first child process of the first
firefox.exe process.
Differential Revision: https://phabricator.services.mozilla.com/D4971
--HG--
extra : rebase_source : 3d323362f80f7199c3cd81c31cf831ab877416e3
The launcher process needs a couple of flags to work correctly under talos.
This patch sets those flags.
Differential Revision: https://phabricator.services.mozilla.com/D4970
--HG--
extra : rebase_source : b7c012b6f82dfe4f01579566f3a8d0d010fb4054
We do not have a test case in talos that has many files to be loaded on start. This change adds 100
files, each around 1000 lines long.
Differential Revision: https://phabricator.services.mozilla.com/D3308
--HG--
extra : moz-landing-system : lando
This makes it much easier to update existing consumers of
XPCOMUtils.enumerateCategoryEntries to use the category manager directly.
It also, unfortunately, requires updating existing category manager consumers
to use the Services getter in order to avoid ESLint errors.
Differential Revision: https://phabricator.services.mozilla.com/D4278
--HG--
extra : rebase_source : fb9fd9b21db80af472ff6250a2e9a35e8d538147
This patch uses the new xperf analyzer to determine the duration of time from
the start of the first firefox process to the session store window restored
event.
I'd like to have this running for a little bit to collect some data points
before we flip the switch to enable the launcher process by default.
--HG--
extra : rebase_source : e305bfed6e14d79643652c7de2703dd501c8be98
This only includes functions that seem to be using it to reference a window.
There are other instances where it's used as a generic chrome URI, and those
are left unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D3806
--HG--
extra : moz-landing-system : lando
We do not have a test case in talos that has many files to be loaded on start. This change adds 100
files, each around 1000 lines long.
Differential Revision: https://phabricator.services.mozilla.com/D3308
--HG--
extra : moz-landing-system : lando
This patch uses the new xperf analyzer to determine the duration of time from
the start of the first firefox process to the session store window restored
event.
I'd like to have this running for a little bit to collect some data points
before we flip the switch to enable the launcher process by default.
This code provides a generic abstraction layer above xperf events that allows
the user to express more sophisticated queries from the data.
XPerfAttribute derives data from one or more XPerfEvents. Events may be
composed into more complex events via subclasses of EventExpression.
See some of the example in main() for an idea of how these classes all fit
together.
This code is incomplete as far as being able to replace the existing xperf I/O
tests, though I would ideally like to flesh this out more such that we could
eventually use this analyzer for all of our future xperf needs.
Note that this code was originally developed for python 3 and backported to
python 2, and its revision history is available at
https://github.com/dblohm7/xperf.
In beta, we still have the old jsterm, so we need to adjust
the test code in this case. Which means reverting back
to what we were doing: manually triggering the autocompletion
start by calling updateAutoCompletion.
Differential Revision: https://phabricator.services.mozilla.com/D3350
--HG--
extra : moz-landing-system : lando
We can now simply call setInputValue and the autocompletion
will happen. Since we are forcing the call to jsterm.complete,
there were 2 calls made to the server, making the measurements
in the test erroneous.
This also revealed a race in setInputValue: the text was
set by codeMirror before the cursor was actually moved. Which
means we were sending an erroneous autocompletion query to the
server.
We use codeMirror.operation to tell codeMirror to both set the
text and the cursor in a single operation.
Differential Revision: https://phabricator.services.mozilla.com/D3192
--HG--
extra : moz-landing-system : lando
Since older versions of Windows still use the old field name, I modified
getIndex to accept a variadic number of possible column names, attempting to
resolve each one.
This ensures that the analysis works both with older versions of Windows, as
well as new ones that employ the new field name.
--HG--
extra : rebase_source : 6dd8b3e820d532a1512bb87e9480845e3ff099bb
Since older versions of Windows still use the old field name, I modified
getIndex to accept a variadic number of possible column names, attempting to
resolve each one.
This ensures that the analysis works both with older versions of Windows, as
well as new ones that employ the new field name.
--HG--
extra : rebase_source : ba71787e6dc766071037d75e2148c9921e860952
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
The term "tab actor" was used ambiguously to mean either the "target actor
representing a tab" or "a child actor of the tab target actor" (such as the
console actor). Here we rename the second case to "target-scoped actor".
Differential Revision: https://phabricator.services.mozilla.com/D1760
--HG--
rename : devtools/client/debugger/test/mochitest/browser_dbg_tabactor-01.js => devtools/client/debugger/test/mochitest/browser_dbg_target-scoped-actor-01.js
rename : devtools/client/debugger/test/mochitest/browser_dbg_tabactor-02.js => devtools/client/debugger/test/mochitest/browser_dbg_target-scoped-actor-02.js
