Problem
The Appearance monospace-font picker determines whether an installed family is monospaced by measuring eight glyphs in four variants on a canvas. That is up to 32 synchronous measureText() calls per family, plus Chromium's local-font and style resolution work.
On the affected system, Local Font Access returned 710 unique families. A complete classification can therefore perform up to 22,720 canvas measurements in the renderer.
This workload affects the Electron desktop client more severely than the web client in the testing done so far. In Electron, interacting with the monospace picker left the renderer UI unresponsive for more than five minutes. The T3 server was still running: requests sent from a phone through the remote feature continued to work. This points to renderer/main-thread starvation rather than a server deadlock.
PR #5642 prevents this work from starting merely because Settings > Appearance opened. It also splits the classification into time-bounded batches. That fixes page navigation on the affected installation, but it does not remove the catalog-wide check: interacting with the monospace picker can still trigger the expensive scan and freeze the Electron UI.
Why the check exists
Cell-grid surfaces such as the terminal require equal character advances. A proportional code font can render text at widths that do not match the cursor and selection grid.
The current check measures i, M, W, 0, @, #, ., and space in regular, bold, italic, and bold italic variants. A family passes when the measured advances match within the configured tolerance.
Desired behavior
- Opening Appearance, opening either font picker, searching, scrolling, and highlighting options must not start a catalog-sized canvas loop.
- The Electron renderer must remain responsive with large installed-font catalogs.
- Search and browsing should cover the complete installed-family catalog.
- A proportional family must not silently become the terminal/code font.
- The behavior must be verified separately in the Electron desktop client and the web client because Electron appears more affected.
- Permission denial and browsers without Local Font Access must keep the existing manual-input fallback.
Possible approaches
1. Validate only the selected family
Show the complete virtualized catalog and run the monospace check only when the user selects a family. This bounds an interaction to at most 32 measurements and can cache the result by family.
Tradeoff: proportional families appear in the monospace picker and are rejected after selection instead of being removed in advance.
This is currently the smallest and most promising approach. The interface-font picker already shows that the complete catalog can be searched and browsed without the monospace classification step.
2. Keep a bounded search-first collection
Expose only a fixed number of matches, while searching all installed families. Include a compact, non-wrapping count so the list does not look complete.
Tradeoff: browsing is incomplete and the limit is an arbitrary product constraint. The list geometry must reserve explicit space for the count.
3. Progressive or infinite loading
Add already-enumerated families to the picker in pages.
Tradeoff: Local Font Access returns the complete catalog at once, and the list is already virtualized. Pagination reduces the combobox collection size but does not reduce monospace-classification work unless classification is also made lazy. It adds loading, keyboard-focus, selection, and collection-update states.
4. Background classification
Move classification away from the Electron renderer, for example with a worker and OffscreenCanvas, or by parsing local font metadata obtained from FontData.blob().
Tradeoff: font availability and metrics must be proven equivalent across Electron and supported browsers. This approach also needs cancellation, caching, progress, invalidation, memory limits, and a fallback when worker font APIs are unavailable.
5. Lazy or idle classification
Classify visible families or small batches only when the browser is idle, and cache results.
Tradeoff: it eventually performs the same total work, may consume CPU for a long time, and can cause options to move or disappear while the user navigates. The Electron failure shows that yielding alone is not sufficient evidence of responsiveness.
Optimization and investigation leads
- Cache successful and failed checks by family.
- Short-circuit after the first unequal variant.
- Record family count, classification duration, measurement count, long tasks, client surface, and Electron/Chromium version.
- Compare the cost of canvas metric probing with parsing fixed-pitch metadata such as OpenType
post.isFixedPitch and OS/2 PANOSE proportion data. - Confirm whether one selected-family probe is fast enough on the affected Electron installation.
- Test catalogs around 700 real families in both Electron and the web client.
- Keep popup layout measurements independent of result-count or progress messages.
Acceptance criteria
- No catalog-wide monospace classification runs during page load or ordinary picker interaction.
- Selecting one family performs bounded validation and preserves the previous preference when validation fails.
- The UI remains interactive during manual testing in Electron with the affected catalog.
- The web client retains equivalent search, selection, and fallback behavior.
- Focused tests cover proportional rejection, cache behavior, and the absence of classification during open/search/scroll.
Problem
The Appearance monospace-font picker determines whether an installed family is monospaced by measuring eight glyphs in four variants on a canvas. That is up to 32 synchronous
measureText()calls per family, plus Chromium's local-font and style resolution work.On the affected system, Local Font Access returned 710 unique families. A complete classification can therefore perform up to 22,720 canvas measurements in the renderer.
This workload affects the Electron desktop client more severely than the web client in the testing done so far. In Electron, interacting with the monospace picker left the renderer UI unresponsive for more than five minutes. The T3 server was still running: requests sent from a phone through the remote feature continued to work. This points to renderer/main-thread starvation rather than a server deadlock.
PR #5642 prevents this work from starting merely because Settings > Appearance opened. It also splits the classification into time-bounded batches. That fixes page navigation on the affected installation, but it does not remove the catalog-wide check: interacting with the monospace picker can still trigger the expensive scan and freeze the Electron UI.
Why the check exists
Cell-grid surfaces such as the terminal require equal character advances. A proportional code font can render text at widths that do not match the cursor and selection grid.
The current check measures
i,M,W,0,@,#,., and space in regular, bold, italic, and bold italic variants. A family passes when the measured advances match within the configured tolerance.Desired behavior
Possible approaches
1. Validate only the selected family
Show the complete virtualized catalog and run the monospace check only when the user selects a family. This bounds an interaction to at most 32 measurements and can cache the result by family.
Tradeoff: proportional families appear in the monospace picker and are rejected after selection instead of being removed in advance.
This is currently the smallest and most promising approach. The interface-font picker already shows that the complete catalog can be searched and browsed without the monospace classification step.
2. Keep a bounded search-first collection
Expose only a fixed number of matches, while searching all installed families. Include a compact, non-wrapping count so the list does not look complete.
Tradeoff: browsing is incomplete and the limit is an arbitrary product constraint. The list geometry must reserve explicit space for the count.
3. Progressive or infinite loading
Add already-enumerated families to the picker in pages.
Tradeoff: Local Font Access returns the complete catalog at once, and the list is already virtualized. Pagination reduces the combobox collection size but does not reduce monospace-classification work unless classification is also made lazy. It adds loading, keyboard-focus, selection, and collection-update states.
4. Background classification
Move classification away from the Electron renderer, for example with a worker and
OffscreenCanvas, or by parsing local font metadata obtained fromFontData.blob().Tradeoff: font availability and metrics must be proven equivalent across Electron and supported browsers. This approach also needs cancellation, caching, progress, invalidation, memory limits, and a fallback when worker font APIs are unavailable.
5. Lazy or idle classification
Classify visible families or small batches only when the browser is idle, and cache results.
Tradeoff: it eventually performs the same total work, may consume CPU for a long time, and can cause options to move or disappear while the user navigates. The Electron failure shows that yielding alone is not sufficient evidence of responsiveness.
Optimization and investigation leads
post.isFixedPitchand OS/2 PANOSE proportion data.Acceptance criteria