[Bug]: Playwright Test for VS Code: Missing Font Glyphs in Dropdown Menus

[svicalifornia]

Version

1.42.1

Steps to reproduce

In the VS Code extension (Playwright Test for VS Code), I'm seeing missing glyphs for the selected state of all dropdown menus:

When each dropdown is open, the text of the options displays normally:

Expected behavior

The text of the selected option of each dropdown should appear correctly when the dropdown menu is not open.

Actual behavior

The text of the selected option of each dropdown is replaced with "missing glyph" boxed question marks.

Additional context

No response

Environment

System:
    OS: macOS 15.7.3
    Memory: 95.39 MB / 16.00 GB
  Binaries:
    Node: 16.20.2 - ~/Library/Caches/fnm_multishells/49787_1769538747222/bin/node
    Yarn: 1.22.15 - /opt/homebrew/bin/yarn
    npm: 8.19.4 - ~/Library/Caches/fnm_multishells/49787_1769538747222/bin/npm
  Languages:
    Bash: 3.2.57 - /bin/bash

[vladlearns]

set font-family + font-size on select (same as input) so both closed + open states use the same font and glyphs exist, looks fixed:

[pavelfeldman]

Looks like this is working for people.

[svicalifornia]

@vladlearns created a PR to fix, which hasn't been merged yet. Please reopen this issue.

[svicalifornia]

@pavelfeldman Please see PR microsoft/playwright-vscode#752 (created by @vladlearns); his screenshot above was taken after his PR fix. This issue is not fixed until that PR gets merged. Please reopen this issue.

[Skn0tt]

@svicalifornia @vladlearns can you elaborate on how this happens? Is this in a special environment or with special vscode config? I'd like to understand how this can happen, these dropdowns don't contain any special characters.

[vladlearns]

@Skn0tt honestly I noticed that input has font set, but the select does not and it fell back to the sys default - expected for these el-s

on old macos it looks fine, since it falls back to helvetica, but on this specific macos version, that default fallback happens to be a last resort font, I recognized it from a looong time ago, ex:
https://discussions.apple.com/thread/253635140
https://issues.chromium.org/issues/41359213
https://www.reddit.com/r/macOS26Tahoe/comments/1mq4go2/font_rendering_issue_w_chromium_browsers/

initially just wanted to do font-family: inherit - is the lazier and cleaner way, just to inherit the parent container styles, but my fix is actually safer IMHO ofc, because input and select will always look the same

hope it helps!

[Skn0tt]

I don't quite follow. If it was a Chromium bug in 2017, why would it occur today in VS Code? And if the bug reocurred, shouldn't it be fixed in Chromium and/or VS Code, instead of in an extension?

[vladlearns]

I don't quite follow. If it was a Chromium bug in 2017, why would it occur today in VS Code? And if the bug reocurred, shouldn't it be fixed in Chromium and/or VS Code, instead of in an extension?

@Skn0tt , hello! I will answer one by one:

1. the refs I've shared are just examples of a last resort font in similar issues, not this exact one;
2. I don't know why it fails here, might be something to do with the combo of a renderer and macos;
3. why fix in the extension - we are not fixing the underlying bug, we are just making sure, that if something like this happens, we will always have an explicit fallback set, given that we already have the font chain for an input tag, moving it to a var and having an explicit fallback looks like a good way of solving the issue, without diving too deep into the chain of underlying stuff and fixing something that we should leave to the separation of concerns

cheers!

[Skn0tt]

I appreciate the willingness to fix the bug, but this is the kind of thing that needs to be fixed upstream in VS Code. Please report it there.