microsoft / microsoft/vscode

`editor.allowVariableFonts: false` silently prevents extension editor decorations from rendering

Open
#330,695 1 comment 0 reactions 1 assignee Claimed by @aiday-mar View on GitHub
bug font-token-customization
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

## Environment

- VS Code: 1.128.0 (commit fc3def6774c76082adf699d366f31a557ce5573f), arm64
- OS: macOS (reproduced on two machines, macOS 15.x — one freshly updated), settings synced via Settings Sync
- Reproduces on separate install and after cache purge; profile-independent given the one setting

## Summary

Note on AI use in this issue post: A fair bit of the debugging was done by Claude Fable here, but I have verified the steps to reproduce myself and the issue does seem to be as described. It was really quite painful to pin down.

Setting `"editor.allowVariableFonts": false` causes text editor decorations created via
`vscode.window.createTextEditorDecorationType()` to silently not render — no error, no
warning, no log output. The extension host runs normally: the decoration type is created
and `TextEditor.setDecorations()` is called with correct ranges (verified by attaching an
inspector to the extension host), but nothing is painted and no decoration CSS/DOM
elements appear in the renderer.

The decorations affected appear to be those whose render options include font-related
properties (`fontStyle` / `fontWeight`), **even when the value is just `"normal"`** —
i.e. the decoration does not actually use variable-font features at all. Instead of
ignoring the font properties, the entire decoration (background colour included) is
dropped. Decorations without font properties (e.g. the built-in merge-conflict
extension's) are unaffected.

The same drop also occurs in screen-reader/accessibility mode via the sibling setting
`editor.allowVariableFontsInAccessibilityMode` (verified) — which may explain historical
reports of extension highlights disappearing when accessibility mode is enabled.

## Steps to reproduce

This is what I did to test cleanly:

1. Fresh/empty profile.
2. Install any extension that highlights via decorations with font properties in its
decoration type (verified with Better Todo Tree, whose decoration types always set
`fontWeight: "normal"` / `fontStyle: "normal"`). Open a file containing `// TODO: test`
— the line is highlighted, as expected.
3. Add `"editor.allowVariableFonts": false` to settings.
4. The highlight disappears (immediately or on next re-decoration) and never renders
again. No error anywhere; the extension's tree/status features keep working, so users
blame the extension.

Suggested minimal API-level repro (extension dev host):

```js
const t = vscode.window.createTextEditorDecorationType({
backgroundColor: '#e5c890',
isWholeLine: true,
fontWeight: 'normal', // <- presence of this (even "normal") triggers the drop
fontStyle: 'normal',
});
vscode.window.activeTextEditor.setDecorations(t, [new vscode.Range(0, 0, 0, 1)]);
```

Renders with default settings; renders nothing with `"editor.allowVariableFonts": false`.

## Expected

Either:
- decorations render normally, with only variable-font-specific properties ignored, or
- at minimum, some diagnostic (log/warning) that decorations were suppressed and why.

`fontWeight: "normal"` / `fontStyle: "normal"` should never count as "uses variable fonts".

## Why this is nasty in practice

- The setting sounds innocuous ("Controls whether variable fonts can be used" — "false"
reads like a safe/performance choice) and is suggested in various tuning guides.
- It syncs via Settings Sync, so the breakage follows the user to other machines. It might not be noticed until the extension is next used, which can be a while after the setting change; it's hard to attribute.
- The failure is totally silent, so users debug the *extensions* (in my case: a fair bit of
intermittent confusion, extension swaps, reinstalls, cache purges, and an extension
bisect that could never converge because no extension was at fault).
- Related test plan: #253007 (variable fonts; decoration font properties gated behind
this setting) — this issue is about the gate discarding whole decorations rather than
just the gated font properties. Possibly also related: #237584 (GPU renderer support
for font-weight in decorations).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.