Skip to content

Deploy September 3, 2026 - #6303

Merged
fatadel merged 52 commits into
productionfrom
main
Sep 3, 2026
Merged

Deploy September 3, 2026#6303
fatadel merged 52 commits into
productionfrom
main

Conversation

@fatadel

@fatadel fatadel commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

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: 高乐喆

mozilla-pontoon and others added 30 commits August 11, 2026 01:50
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.
canova and others added 22 commits August 24, 2026 16:36
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>
@fatadel
fatadel requested a review from canova as a code owner September 3, 2026 15:09
@fatadel
fatadel merged commit 8a4d03e into production Sep 3, 2026
38 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants