We used to have animations during tab opening/closing, but this was introducing
intermittents as we were not correctly waiting for animation's end.
MozReview-Commit-ID: 2mscsA8Uosd
Differential Revision: https://phabricator.services.mozilla.com/D10263
--HG--
extra : moz-landing-system : lando
This seems to silence the intermittent, even though it doesn't explain
why we started spiking after moving TabClient to a Front.
Differential Revision: https://phabricator.services.mozilla.com/D9755
--HG--
extra : moz-landing-system : lando
The biggest change here is that the tart.html page that drives the
test (not to be confused with the pages loaded in new tabs during the
test) moves from a chrome: page inside the extension to a regular http:
page. That also required revamping the communication between tart.html
and the extension. The rest of the changes are just the packaging and
startup mechanics for the test extension.
Differential Revision: https://phabricator.services.mozilla.com/D8807
--HG--
rename : testing/talos/talos/tests/tart/addon/bootstrap.js => testing/talos/talos/tests/tart/addon/api.js
rename : testing/talos/talos/tests/tart/addon/content/blank.icon.html => testing/talos/talos/tests/tart/addon/chrome/blank.icon.html
rename : testing/talos/talos/tests/tart/addon/install.rdf => testing/talos/talos/tests/tart/addon/manifest.json
rename : testing/talos/talos/tests/tart/addon/content/tart.html => testing/talos/talos/tests/tart/tart.html
rename : testing/talos/talos/tests/tart/addon/content/tart.ico => testing/talos/talos/tests/tart/tart.ico
extra : source : 3133f6ab1bd8ea2aa261f8e9024ab3fb8eb0ddcb
This is to know if DAMP works without e10s shims.
MozReview-Commit-ID: 2IZGlenkuzb
Differential Revision: https://phabricator.services.mozilla.com/D8839
--HG--
extra : moz-landing-system : lando
I'm not sure at which point this broke, but the current dump_syms_mac exits with
an error when it's run on a XUL binary on my machine.
MozReview-Commit-ID: 8nV7n7G5MKS
--HG--
extra : rebase_source : e84810e6df0767c206f0a61986a5403577845a85
extra : amend_source : 107e41210966c79022391a89d98b976f2ae2ab4a
This gets accessed in beta simulations since xperf has been enabled on Windows 10.
Differential Revision: https://phabricator.services.mozilla.com/D8516
--HG--
extra : moz-landing-system : lando
This is a pretty straightforward conversion. We deliberately continue
to use chrome: urls in this test since those are loaded in the parent
process so test measurements will not include additional noise from
IPC to a content process.
--HG--
rename : testing/talos/talos/tests/tresize/addon/bootstrap.js => testing/talos/talos/tests/tresize/addon/api.js
rename : testing/talos/talos/tests/tresize/tresize-test.html => testing/talos/talos/tests/tresize/addon/chrome/tresize-test.html
rename : testing/talos/talos/tests/tresize/addon/install.rdf => testing/talos/talos/tests/tresize/addon/manifest.json
extra : rebase_source : d5449086194225b737c70885881ac297d3c4ecb6
Some new features were added to MozAfterPaint events in bugs 1264409 and
1264798 to allow tests to make more accurate measurements. Updating
tresize to use these features is not directly related to the main goal
of this bug, but lets do it anyway while we're touching tresize...
--HG--
extra : rebase_source : ba966b0f22c1ceb7fa1a747e75b159a30997929f
The talos tresize test was originally written as a "startup" test which
is confusing since it doesn't measure anything that happens during
browser startup. Convert it here to the "pageloader" style, which
mostly involves moving files around, also some changes to how the test
results are reported to the Talos framework.
--HG--
rename : testing/talos/talos/startup_test/tresize/addon/bootstrap.js => testing/talos/talos/tests/tresize/addon/bootstrap.js
rename : testing/talos/talos/startup_test/tresize/addon/chrome.manifest => testing/talos/talos/tests/tresize/addon/chrome.manifest
rename : testing/talos/talos/startup_test/tresize/addon/content/Profiler.js => testing/talos/talos/tests/tresize/addon/content/Profiler.js
rename : testing/talos/talos/startup_test/tresize/addon/content/framescript.js => testing/talos/talos/tests/tresize/addon/content/framescript.js
rename : testing/talos/talos/startup_test/tresize/addon/content/tresize.js => testing/talos/talos/tests/tresize/addon/content/tresize.js
rename : testing/talos/talos/startup_test/tresize/addon/install.rdf => testing/talos/talos/tests/tresize/addon/install.rdf
rename : testing/talos/talos/startup_test/tresize/addon/content/tresize-test.html => testing/talos/talos/tests/tresize/tresize-test.html
extra : rebase_source : a242750692e7449788cf58d620b24bffc53a32ff
tresize-test.html attempts to load
"resource://talos-powers/TalosPowersContent.js", but this might not be available
yet if the tresize add-on hasn't loaded. This patch changes the location of this
resource to a relative path, which should always be available. Additionally,
this patch awaits on TalosPowers.loadPromise before using talos APIs.
Differential Revision: https://phabricator.services.mozilla.com/D7312
--HG--
extra : moz-landing-system : lando
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
browser-idle-startup-tasks-finished will kick off some caching that can influence
future runs in the same profile. We want to make sure that we properly create
that cache when running Talos.
MozReview-Commit-ID: 9Ydt1ur3tsj
--HG--
extra : rebase_source : 059fea98d2c77c7a89e36dff7b6c85dfee3f6e57
goQuitApplication does the work of closing all windows anyways, so closing the
window is superfluous. goQuitApplication is also going to be checking for certain
operations to be finished before doing that, which could be influenced by closing
a window early.
MozReview-Commit-ID: 9gJ0ZRn753F
--HG--
extra : rebase_source : bcf902e332fd6a5aa82e40933e6b5d15c0f73cea
When running talos locally with --geckoProfile set, the latest gecko-profile archive will automatically be loaded in perf-html.io using the view-gecko-profile tool. To disable this automatic perf-html.io launching, set TALOS_DISABLE_PROFILE_LAUNCH=1.
MozReview-Commit-ID: 8tpLnsPAXD9
--HG--
extra : rebase_source : 66d03b55103e9771c4c8c4c70ff67212f24c1124
This moves all of the global prefs that were previously defined
in testing/talos/talos/config.py, into a new "perf" profile under
testing/profiles/perf/user.js.
This perf profile will be shared with raptor, so changes to one
framework will result in changes to the other.
MozReview-Commit-ID: JRxZEDlPu6b
--HG--
extra : rebase_source : 38f61eb6f9dd3e8dd9e0425ffe32dbdf845fcf65
This makes debugging failures extremely difficult, and tends to confuse
developers who add debugging logs and can't understand why they're not showing
up.
MozReview-Commit-ID: Wajt2JczuY
--HG--
extra : rebase_source : 497d78a915ad92707ba5f7d5b437ec1dfbc5b8f8
This is based on a script I'd already created to migrate test extensions to
the JSON format we use to generate fixture add-ons.
The delay update add-ons used invalid XML in their manifests, which the
built-in parser ignored but the new parser doesn't accept, so I had to fix
those, too.
MozReview-Commit-ID: BnuxZiBhhJL
--HG--
rename : toolkit/mozapps/extensions/internal/UpdateRDFConverter.jsm => toolkit/mozapps/extensions/internal/RDFManifestConverter.jsm
extra : source : 292cf80054b4734a0d7c84e987f68e229f2ccc24
extra : histedit_source : 1072def8a28149a9f9882825f73435336b205072%2C2c72e58aa973fe24867868d06dcc63235dd68da2
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
The test was measuring the time spent to expand an object only
containing alphanumeric properties. But due to how we fetch properties,
this only cover a part of data fetching performances.
This patch adds numeric and Symbol indexes in order to have a more precise
view of what is happening when expanding an object in the console.
MozReview-Commit-ID: AwSRLwnC35T
--HG--
extra : rebase_source : 0cc2a9502ca739956de7371cf288b6e9bbc446a7
MozLayerTreeReady is fired once the parent process hears from the compositor that the layers
from a remote tab have been painted and uploaded. For tab switching, this is a far more accurate
assessment of when the tab is actually presented to the user, since this is the event that the
async tab switcher also listens for.
MozReview-Commit-ID: 8oy5MqNwWNS
--HG--
extra : rebase_source : 0b96197f5ebae486109ccb0a691f11db83dd360a
This Talos test is more concerned with how much it costs to switch tabs in the simple case
where the tab strip isn't scrolling around. To avoid having that noise introduced, the tab
strip is hidden by default. Unfortunately, with the way that we style the tabs in Photon,
some parts of the tabs are still visible and reintroduces the noise. Setting opacity to
0 hides it fully.
MozReview-Commit-ID: HH0pWGRcg2g
--HG--
extra : rebase_source : 4bfd8be5a9669914f559b5c9fbe2c69699eeeade
While we are removing a bunch of stuff and breaking backwards compatibility, I
figured this would be a good time to also change some of the APIs. These APIs
aren't used much in mozilla-central (and this patch updates the few places that
do).
This rolls the 'install_addons()' and 'install_addon_from_path' method into a
single 'install' method. This install method can accept a string or list of
paths to an individual addon (directory or .xpi), or a directory containing
addons.
This also renames Profile.addon_manager to Profile.addons, which reads better.
MozReview-Commit-ID: 7vDPnG4cKqu
--HG--
extra : rebase_source : 62f8613b9824e06e698d5af8dcbb4bcb07b8079e
Move the scripts and bootstrapping code that was in the overlay into a file
loaded by bootstrap file.
MozReview-Commit-ID: EIqQnU7rCbq
--HG--
extra : rebase_source : 502e0fbe8d5b17af0fb4c4507dae50ae65dedd2e
In order to remove support for non-bootstrapped extensions, the remaining test
automation extensions need to be migrated to bootstrapped extensions. These
extensions all work by loading a single component, either with a
profile-after-change or command line handler. This is a straightforward
conversion of those components to bootstrap.js scripts.
MozReview-Commit-ID: 5uyNSqRPIVR
--HG--
rename : services/sync/tps/extensions/tps/components/tps-cmdline.js => services/sync/tps/extensions/tps/bootstrap.js
rename : testing/talos/talos/pageloader/components/tp-cmdline.js => testing/talos/talos/pageloader/bootstrap.js
rename : testing/talos/talos/startup_test/sessionrestore/addon/SessionRestoreTalosTest.js => testing/talos/talos/startup_test/sessionrestore/addon/bootstrap.js
rename : testing/talos/talos/talos-powers/components/TalosPowersService.js => testing/talos/talos/talos-powers/bootstrap.js
rename : tools/quitter/QuitterObserver.js => tools/quitter/bootstrap.js
extra : rebase_source : 738264d0ec8701aa5cf93c6dac958d88756c1e55
extra : source : 71d65d6b64997bc608a1cb3c924be35bbd460b39
Mike Conley
Alexandre Poirot
Csoregi Natalia
Julian Descottes
Rob Wood
Andrew Swan
Mark Banner
Marco Castelluccio
Noemi Erli
florin.strugariu
Markus Stange
Sebastian Hengst
Ryan VanderMeulen
Dana Keeler
yulia
shindli
Aaron Klotz
Margareta Eliza Balazs
Jonathan Kingston
Brindusan Cristian
arthur.iakab
Nicolas Chevobbe
Robert Strong
Matt Woodrow
Daniel Varga
Joel Maher
Gurzau Raul
ui.manish
Ciure Andrei
Kris Maglione
Tiberius Oros
Brian Grinstead
Cosmin Sabou
Simon Fraser
Florian Quèze
Bogdan Tara
Emilio Cobos Álvarez
Jonathan Watt
Dão Gottwald
Boris Zbarsky
Ionut Goldan
Felipe Gomes
Rob Wu
Kirk Steuber
Andreea Pavel
Kartikaya Gupta
Jason Laster
Andrew Halberstadt
Christoph Kerschbaumer
J. Ryan Stinnett
Henrik Skupin
Peter Van der Beken
Ryan Hunt
Marco Bonardo
Dorel Luca
Gabriel Luong
Mike de Boer
Jan Odvarko
Narcis Beleuzu
Tim Nguyen
Brendan Dahl