Deploy September 3, 2026 - #6303
Merged
Merged
Conversation
Co-authored-by: ravmn (es-CL) <ravmn@ravmn.cl>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Co-authored-by: giray (tr) <giray@nightlylab.com>
Co-authored-by: Luna Jernberg (sv-SE) <bittin@cafe8bitar.se> Co-authored-by: Peter Kihlstedt (sv-SE) <peter.kihlstedt@gmail.com>
Co-authored-by: Mark Heijl (nl) <markh@babelzilla.org>
Consumes the secPurpose and deliveryType Network marker fields added in bug 2060983, as tooltip details plus hidden schema fields so searching the network chart for "prefetch" narrows to those requests. Fixes #6248 Co-authored-by: Nazım Can Altınova <canaltinova@gmail.com>
Document field:value, name: and - negation in `thread markers --help` and `guide`, and correct guide's "Filter by name substring", which was wrong in both directions: a bare --search term also matches payload text, while the name: prefix that narrows to the name went unmentioned. Note name: is not a name-only filter -- "name" is also a schema-declared payload key on Text/TextStack markers, so name:X tests both.
Marker times in --list text and --json disagreed by a constant rootRange.start (9.2ms on a CI profile): the text path subtracted the profile start, the raw JSON path did not. Both now report ms since the profile start, matching what profiler.firefox.com displays. counter info had the same contradiction (text 91,810ms vs JSON 101.02161) and is fixed the same way. The rebasing moves into the query layer, changing the value of these JSON fields, previously raw processed-profile timestamps: flatMarkers[].start, byType[].topMarkers[].start, customGroups[..].topMarkers[].start (incl. subGroups), marker info start/end, stack.capturedAt, and counter info rangeStart/rangeEnd. Durations are differences and do not move; context.rootRange stays raw, being the origin the others subtract.
Unfiltered thread markers failed with "Maximum call stack size exceeded" on threads above roughly 1M markers: computeRateStats spread the whole gap array into Math.min/Math.max, once per marker name group. Compute the min, max and mean in a single pass instead.
In the past, the way to get the library for a frame would be to go frame -> func -> resource -> lib. For native frames, the resource is of type Library and points at the lib. This had the following implications: - Native frames cannot ever have a resource of a non-Library type. - If two native frames want to share a func, they must also share the same library - otherwise they'll be in a different resource, and different resource means different func. This makes it hard to represent a few cases: - JS JIT frames with assembly. To have assembly, we must have a native library, but we also want JIT frames to have a JS file as their resource, and we want JITted frames for a JS function to share the func with non-JITted frames (interpreter frames) of the same JS function. - Comparison profiles / the "diff" thread for different builds, with assembly code. For example if you have two Firefox builds, one with and one without a patch, they'll have different libxul.so libraries, but you still want to combine C++ functions of the same name in the diffed tree. - Resources for Rust crates (not implemented here): We might want to assign different Rust frames from the same native binary to different resources, with one resource per Rust crate. This commit makes it so that frames now point at their library directly, and removes the lib column from the resourceTable. A resource of type Library only carries the library's name; several libs can share one. mergeLibs used to key on name + debugName, which collapsed two builds of the same library into one lib (and one resource). Now it keeps the libs separate but still collapses the resources by name. For func-only contexts there is no longer a func -> lib edge. formatFunctionNameWithLibrary and the new getLibNameForFunc read the name off the func's resource, which is all they ever needed. profile-query's functionInfo, which wants the full Lib record, scans the frame table once per query.
frameTable.address uses -1 rather than null for "no address", so the existing null check was always useless.
<!-- profiler-preview-links:start --> [Main](https://main--perf-html.netlify.app/) | [Deploy preview](https://deploy-preview-6258--perf-html.netlify.app/) <!-- profiler-preview-links:end --> In the past, the way to get the library for a frame would be to go frame -> func -> resource -> lib. For native frames, the resource is of type Library and points at the lib. This had the following implications: - Native frames cannot ever have a resource of a non-Library type. - If two native frames want to share a func, they must also share the same library - otherwise they'll be in a different resource, and different resource means different func. This makes it hard to represent a few cases: - JS JIT frames with assembly. To have assembly, we must have a native library, but we also want JIT frames to have a JS file as their resource, and we want JITted frames for a JS function to share the func with non-JITted frames (interpreter frames) of the same JS function. - Comparison profiles / the "diff" thread for different builds, with assembly code. For example if you have two Firefox builds, one with and one without a patch, they'll have different libxul.so libraries, but you still want to combine C++ functions of the same name in the diffed tree. - Resources for Rust crates (not implemented here): We might want to assign different Rust frames from the same native binary to different resources, with one resource per Rust crate. This commit makes it so that frames now point at their library directly, and removes the lib column from the resourceTable. A resource of type Library only carries the library's name; several libs can share one. mergeLibs used to key on name + debugName, which collapsed two builds of the same library into one lib (and one resource). Now it keeps the libs separate but still collapses the resources by name. For func-only contexts there is no longer a func -> lib edge. formatFunctionNameWithLibrary and the new getLibNameForFunc read the name off the func's resource, which is all they ever needed. profile-query's functionInfo, which wants the full Lib record, scans the frame table once per query.
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com> Co-authored-by: Nazım Can Altınova <canaltinova@gmail.com>
Co-authored-by: Andreas Pettersson (sv-SE) <amvpet@gmail.com>
…#6267) thread network documented --limit 0 as "all requests" while thread markers rejected it as "must be a positive integer". Accept 0 everywhere --limit is taken, and name the omitted count and the expanding flag whenever output is truncated. thread samples/samples-top-down/samples-bottom-up declare --limit but never read it. Left as-is here: removing it is a behaviour change unrelated to accepting 0, and belongs in its own commit.
Co-authored-by: Selim Şumlu (tr) <selim@sum.lu>
Co-authored-by: Selim Şumlu (tr) <selim@sum.lu>
Co-authored-by: 高乐喆 (zh-CN) <gaolezhe@outlook.com>
#6274) `thread network --limit 0` printed "114 requests ... (filtered from 104)" -- a pre-filter total below the count it qualified. totalRequestCount counts only completed legs and incompleteCount only in-flight ones, so redirect and cancel legs are counted by neither and the sum of the two is not the set the filters ran against. Add totalCandidateCount and use it for that total. `profile info`'s "By thread:" row has the same undercount and said only "reqs", so it printed 104 where `thread network` printed 114 for the same thread; it now says "started reqs", which covers the completed and in-flight legs that count includes.
The warning indicators next to the publish panel checkboxes were img elements using warning.svg, which has a hardcoded black fill and stayed black on dark backgrounds. This commit renders them as spans with a background image instead, so they can switch to the light variant (warning-light.svg, already used by the photon message bars) in dark mode.
…6282) The two warning indicators next to the checkboxes duplicated the Localized wrapper boilerplate. Move it into a local WarningIndicator component. I'll use it in another checkbox later for source upload.
So far, the columns we've converted to typed arrays were either always non-empty, or they used -1 as the "no value" sentinel. For the FrameTable, I've opted to not to use -1 sentinel values, and instead have a flags column with a "HasXYZ" flag for each column (e.g. FrameFlags.HasAddress), for the following reasons: - I'd like to use U8 and U16 arrays for the category and subcategory columns. That's already what we use in the derived StackTable. With an external flag we can go up to 256 subcategories without having to use 16 bits. - I'm changing the inlineDepth column into just a "is inline" bool. This is a good fit for a flag. - The address column was using -1 as the "no address" sentinel; having the flag lets us use U32 instead of I32 for the address column and have relative addresses for 4GiB binaries rather than just 2GiB. An alternative I considered (but discarded) was to have a bitset for each column. E.g. one "isInlined" bitset where, in the JSON, each item is a U8 with the bits for 8 different frames. And similarly we could have a "hasCategory" bitset. But that was too many extra columns in my opinion.
<!-- profiler-preview-links:start --> [Main](https://main--perf-html.netlify.app/public/r46sswz6ehg1g8n0b2kvgjsx4y5z6xfngf8xzh0/calltree/?globalTrackOrder=0&thread=0&v=17) | [Deploy preview](https://deploy-preview-6173--perf-html.netlify.app/public/r46sswz6ehg1g8n0b2kvgjsx4y5z6xfngf8xzh0/calltree/?globalTrackOrder=0&thread=0&v=17) <!-- profiler-preview-links:end --> This allows all columns of the frame table to be stored as typed arrays, and reduces the amount of JSON parsing when loading a JSLB profile. Size profile before: https://share.firefox.dev/469V8zL Size profile after: https://share.firefox.dev/4ijXlQp
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Bumps [@humanfs/node](https://github.com/humanwhocodes/humanfs/tree/HEAD/packages/node) from 0.16.6 to 0.16.8. - [Release notes](https://github.com/humanwhocodes/humanfs/releases) - [Changelog](https://github.com/humanwhocodes/humanfs/blob/main/packages/node/CHANGELOG.md) - [Commits](https://github.com/humanwhocodes/humanfs/commits/node-v0.16.8/packages/node) --- updated-dependencies: - dependency-name: "@humanfs/node" dependency-version: 0.16.8 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [fast-uri](https://github.com/fastify/fast-uri) from 3.1.5 to 3.1.7. - [Release notes](https://github.com/fastify/fast-uri/releases) - [Commits](fastify/fast-uri@v3.1.5...v3.1.7) --- updated-dependencies: - dependency-name: fast-uri dependency-version: 3.1.7 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [qs](https://github.com/ljharb/qs) from 6.15.2 to 6.16.0. - [Changelog](https://github.com/ljharb/qs/blob/main/CHANGELOG.md) - [Commits](ljharb/qs@v6.15.2...v6.16.0) --- updated-dependencies: - dependency-name: qs dependency-version: 6.16.0 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…stry Yarn 1 sets npm_config_registry to https://registry.yarnpkg.com in the environment of every script it runs. The npm publish spawned by this script inherited that and tried to upload to the Yarn mirror, which is read-only and doesn't receive the token that ~/.npmrc scopes to registry.npmjs.org, so the publish failed to authenticate. Fixed this issue by setting publishConfig.registry in package.json, which npm applies at publish time regardless of how it was invoked, and by dropping that one inherited variable when the script spawns npm. The other npm_config_* variables are left alone since they may be the user's own configuration, and clearing something like npm_config_userconfig would hide their ~/.npmrc from npm entirely.
npm publish needs a token in ~/.npmrc to start at all, and fails with ENEEDAUTH instead of offering to log you in, so a stale token would only surface after yarn test-all had already run. Check npm whoami up front and run npm login when it fails, which keeps the interactive part at the beginning and skips it when the existing token is still good. The browser round trip npm makes at publish time is the 2FA check on the upload itself and still happens either way. The check is skipped for --dry-run, which uploads nothing and so needs no credentials at all.
yarn build-cli bundles the working copy rather than a commit, so anything uncommitted at publish time ends up in the tarball on npm with no commit or tag matching what users install. Check `git status --porcelain` before the npm login and the test run, print what is dirty and stop there. Untracked files count too, since a source file that isn't committed yet still gets bundled.
The deploying document was outdated a bit since we added the cli and changed the deployment process for a few times. This commit reorganizes the file a bit so we have the whole step indicated properly and with the proper release order. And it also adds a step by step list at the top summarizes everything.
…ment in a better way (#6260) Previously the `yarn publish-cli` wasn't working properly, and that's why I had to use `npm publish ...` manually every time, but that's quite prone to errors. I improved that script and updated the whole documentation so it's easier to follow. These are the things I did, please look at their own commits to see their details: - Improve the `scripts/publish-profiler-cli.mjs` script: - Fixing the yarn attempting to publish to a wrong registery - Log in to npm before publishing (otherwise `npm publish` fails) - Refuse to publish if the working copy is dirty - Improve the publish documentation to reflect the current state of the publish flow. (it was outdated due to the changes we made in the cli publish even before this PR) - See the rendered version here: https://github.com/canova/perf.html/blob/765f2d145eb9a358699b0ff238f3b4011e21bc5f/docs-developer/deploying.md Since I didn't want to publish to our own npmjs package while testing, I used a local verdaccio server to host it and verified that the script indeed works now. Also it looks like there are a lot more changes made than it actually is in deploying.md, mostly because some sections are shifted around and git can't figure that out.
* Pontoon/Firefox Profiler: Update Spanish (Chile) (es-CL) Co-authored-by: ravmn (es-CL) <ravmn@ravmn.cl> * Pontoon/Firefox Profiler: Update Turkish (tr) Co-authored-by: giray (tr) <giray@nightlylab.com> * Pontoon/Firefox Profiler: Update Swedish (sv-SE) Co-authored-by: Luna Jernberg (sv-SE) <bittin@cafe8bitar.se> Co-authored-by: Peter Kihlstedt (sv-SE) <peter.kihlstedt@gmail.com> * Pontoon/Firefox Profiler: Update Dutch (nl) Co-authored-by: Mark Heijl (nl) <markh@babelzilla.org> * Pontoon/Firefox Profiler: Update Swedish (sv-SE) Co-authored-by: Andreas Pettersson (sv-SE) <amvpet@gmail.com> * Pontoon/Firefox Profiler: Update Turkish (tr) Co-authored-by: Selim Şumlu (tr) <selim@sum.lu> * Pontoon/Firefox Profiler: Update Turkish (tr) Co-authored-by: Selim Şumlu (tr) <selim@sum.lu> * Pontoon/Firefox Profiler: Update Chinese (China) (zh-CN) Co-authored-by: 高乐喆 (zh-CN) <gaolezhe@outlook.com> --------- Co-authored-by: Pontoon <pontoon@mozilla.com> Co-authored-by: ravmn (es-CL) <ravmn@ravmn.cl> Co-authored-by: Firefox Profiler [bot] <perf-html@mozilla.com> Co-authored-by: giray (tr) <giray@nightlylab.com> Co-authored-by: Luna Jernberg (sv-SE) <bittin@cafe8bitar.se> Co-authored-by: Peter Kihlstedt (sv-SE) <peter.kihlstedt@gmail.com> Co-authored-by: Mark Heijl (nl) <markh@babelzilla.org> Co-authored-by: Andreas Pettersson (sv-SE) <amvpet@gmail.com> Co-authored-by: Selim Şumlu (tr) <selim@sum.lu> Co-authored-by: 高乐喆 (zh-CN) <gaolezhe@outlook.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes:
[Nazım Can Altınova] Update oxfmt 0.59.0 → 0.63.0 (major) (#6262)
[Andrew Creskey] Show which network requests were prefetched (#6259)
[Florian Quèze] profiler-cli: document the marker field:value search syntax (#6265)
[Florian Quèze] profiler-cli: report one time base for text and JSON output (#6266)
[Florian Quèze] profiler-cli: avoid a stack overflow on large marker threads (#6264)
[Markus Stange] Give the frameTable a lib column (#6258)
[Florian Quèze] profiler-cli: accept --limit 0 as unlimited, and make truncation loud (#6267)
[Florian Quèze] profiler-cli: report the network request count the filters ran against (#6274)
[Nazım Can Altınova] Fix dark mode contrast of the warning icons in the publish panel (#6280)
[Nazım Can Altınova] Extract the publish panel warning indicator into a small component (#6282)
[Markus Stange] More typed arrays in the FrameTable (and a flags column) (#6173)
[Nazım Can Altınova] Improve the profiler-cli publish script and document the whole deployment in a better way (#6260)
[fatadel] 🔃 Sync: l10n -> main (September 3, 2026) (#6301)
[fatadel] Bump profiler-cli version to 0.9.0 (#6302)
And special thanks to our localizers:
es-CL: ravmn
nl: Mark Heijl
sv-SE: Andreas Pettersson
sv-SE: Luna Jernberg
sv-SE: Peter Kihlstedt
tr: Selim Şumlu
tr: giray
zh-CN: 高乐喆