Since markers are stored directly into the buffer:
- We don't need to wait for a sampling run to collect them,
- No markers are left uncollected between the last sampling and the time we stop
the profiler.
Differential Revision: https://phabricator.services.mozilla.com/D49233
--HG--
extra : moz-landing-system : lando
`stopProfilerAndGetThreads()` waits until at least one sample appears in the
main thread, before capturing a profile and stopping the profiler.
`stopProfilerNowAndGetThreads()` does not wait; this should be useful in tests
that may not generate any samples (e.g., using the nostacksampling feature).
Differential Revision: https://phabricator.services.mozilla.com/D49232
--HG--
extra : moz-landing-system : lando
Adds a test for Lintpref and two test files. Also makes some adjustments to `lintpref.yml` to improve support file loading.
Differential Revision: https://phabricator.services.mozilla.com/D49674
--HG--
extra : moz-landing-system : lando
Adds the filepaths of more pref files to Lintpref as well as to its TaskCluster entry. All of the pref files added are noted in bug 1585421.
Differential Revision: https://phabricator.services.mozilla.com/D49363
--HG--
extra : moz-landing-system : lando
Teaches Lintpref to look at `value` matches when considering possible duplicates.
Differential Revision: https://phabricator.services.mozilla.com/D49362
--HG--
extra : moz-landing-system : lando
Replaces the basic pattern-matching in the linter with a more robust regexp. This regexp can strip `name` and `value` from the pref, which will be useful in part 3 of bug 1587180.
Differential Revision: https://phabricator.services.mozilla.com/D49361
--HG--
extra : moz-landing-system : lando
Rather than statically loading the path to `all.js`, Lintpref should look at any file paths in `lintpref.yml`. Also added the `path` field to each error to accommodate multiple files, and a few other code tidiness cleanups.
Differential Revision: https://phabricator.services.mozilla.com/D48626
--HG--
extra : moz-landing-system : lando
The object-client.js file is now a proper protocol.js front,
but is still named after a client.
This is confusing, so we rename and move the file next to other
fronts, and update all consumers to the new terminology.
Differential Revision: https://phabricator.services.mozilla.com/D49878
--HG--
rename : devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/object-client.js => devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/object-front.js
rename : devtools/shared/client/object-client.js => devtools/shared/fronts/object.js
extra : moz-landing-system : lando
Removes all of the duplicate prefs from mobile.js and StaticPrefList.yaml where the `value` field is the same. Carries over comments from mobile.js where needed.
Differential Revision: https://phabricator.services.mozilla.com/D49357
--HG--
extra : moz-landing-system : lando
The BuildReader's 'find_sphinx_variables' function is hardcoded to look for the
SPHINX_TREES and SPHINX_PYTHON_PACKAGE_DIRS variables. But it's otherwise
implemented to find any arbitrary variable (as long as they are a simple list
or dict).
This change simply moves the variable name(s) to the function call. The comment
about possibly wanted to use a higher level AST library to parse other kinds of
variables still applies, but for now this change is good enough to suit my
needs.
Differential Revision: https://phabricator.services.mozilla.com/D48424
--HG--
extra : moz-landing-system : lando
If 'fzf' was installed by mach, then check it's up to date and force update if needed.
Differential Revision: https://phabricator.services.mozilla.com/D49597
--HG--
extra : moz-landing-system : lando
The fix in Bug 1577634 only worked for the beta channel as it didn't consider the RC case.
There's several situations:
* beta without comments --> beta with comments: handled by bug 1577634, but with fallout
* beta with comments --> beta with comments: `channel-prefs.js` is identical so we never need to apply any transforms
* beta with comments --> rc with comments: the channel changes in `channel-prefs.js` (by design) so we apply transforms
* rc with comments --> beta with comments: the channel changes in `channel-prefs.js` (by design) so we apply transforms
By moving the channel fixing transforms forward the file will become identical before we need to try the comment transform. The code breaks early in this case.
The release/esr case is simpler:
* release without comments --> release with comments: handled by comment transform, channel transforms only used for beta tests
* release with comments --> release with comments: `channel-prefs.js` already identical, no transforms applied
Differential Revision: https://phabricator.services.mozilla.com/D49224
--HG--
extra : moz-landing-system : lando
We want to remove flat strings (JSFlatString). With this patch we only expose
linear strings (JSLinearString) to API consumers.
This is very mechanical for the most part, because code typically only cares
about linear strings and not the null-termination aspect.
CTypes's Library.cpp has some Windows-specific code where we relied on null-terminated
strings. This patch adds JS_CopyStringCharsZ for that use case.
Differential Revision: https://phabricator.services.mozilla.com/D48314
--HG--
extra : moz-landing-system : lando
This patch creates a new API to the nsIProfiler interface, through the activeConfiguration
property. It exposes the internal configuration of the profiler. In addition, this information
is serialized into the profile meta object.
Differential Revision: https://phabricator.services.mozilla.com/D48733
--HG--
extra : moz-landing-system : lando
We are not simply excluding all about:blanks because there might be some
about:blank that user really visits. But for others we don't want to include
the first about:blank because when a BrowsingContext is loaded, and if the
principal matches, the first document loaded in it will share the inner window.
Differential Revision: https://phabricator.services.mozilla.com/D47067
--HG--
extra : moz-landing-system : lando
We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They
weren't quite good because:
1. While loading an iframe, they were being registered twice with the same
ids(for about:blank and the real URL) sometimes.
2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child
processes if the parent is in a different process. That may not be the case for
now, but it will be after fission.
So we had to find other IDs to:
1. Determine the Tab of the frames.
2. Determine the URLs of the frames.
For the first use case, we were using nsDocShell::mHistoryId for that purpose
but that was wrong. The closest thing that we can get to a tab ID is
BrowsingContext ID because they don't change after a navigation. But iframes
have different BrowsingContext's, so we still need to create a tree to
construct a tab content. That can be either in the front-end or capture time.
For the second use case, we were using a key pair of mHistoryId and mOSHE. We
now chose to keep inner window IDs for that purpose. Inner window IDs are
unique for each navigation loads because inner window correspond to each JS
window global objects. That's why we can use that without any problem. But one
problem is that we cannot handle `history.pushState` and `history.replaceState`
changes with that change since window global objects won't change during those.
But that was the best thing we can do after fission. So this will be a small
sacrifice for us to keep that functionality working after fission.
In that patch we also remove the registration/unregistration calls. We are
going to add those calls in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D47065
--HG--
extra : moz-landing-system : lando
Having `mProfileBuffer` be a pointer is not really helpful:
- The pointer is never null (It's allocated on ActivePS construction, and
implicitly deleted on ActivePS destruction); it's never moved-from.
- It requires an extra `new` and an extra `delete`.
Differential Revision: https://phabricator.services.mozilla.com/D48650
--HG--
extra : moz-landing-system : lando
Add assertions that all `sInstance` pointers (from both `CorePS` and `ActivePS`)
are not null before being dereferenced.
This is probably more than needed, but it's only `MOZ_ASSERT`s limited to
Nightly, and it should give better feedback in case something goes wrong.
Eventually, I think it would be better to make most methods non-static, and have
a checked reference-to-instance getter.
Differential Revision: https://phabricator.services.mozilla.com/D48649
--HG--
extra : moz-landing-system : lando
The duration file downloader uses the cache directory created by taskgraph generation.
Differential Revision: https://phabricator.services.mozilla.com/D48705
--HG--
extra : moz-landing-system : lando
This should fix the doc builds on Windows, as sphinx-js added Windows support in 2.3.1 and 2.4. We also now get support for variadic args, @deprecated, and @see, along with other features.
sphinx-js 2.7.1 changed the default cwd to be the one containing conf.py, so I also had to twiddle `jsdoc_config_path`.
Let some other pipenv pinnings update themselves as well, as, if I don't, they'll just update themselves the next time somebody runs `mach doc`, dirtying their tree.
I suspect this also fixes bug 1556460, whose equivalent bug in sphinx-js is https://github.com/mozilla/sphinx-js/issues/106. IOW, it should no longer break with versions of jsdoc >= 3.6.
Differential Revision: https://phabricator.services.mozilla.com/D48122
--HG--
extra : moz-landing-system : lando
