Repository navigation
[Firefox] Markdown Preview fails to load workspace CSS via markdown.styles (NS_ERROR_UNKNOWN_HOST for vscode-resource.vscode-cdn.net) #7913
Description
Is there an existing issue for this?
- I have searched the existing issues
OS/Web Information
- Web Browser: Firefox
firefox-151.0-2.fc42.x86_64
- Local OS: Fedora 42
- Remote OS: Fedora 42
- Remote Architecture: amd64
code-server --version: 4.105.1 811ec6c with Code 1.105.1
Steps to Reproduce
Bug Description
When opening a Markdown preview in Firefox, local CSS files referenced in markdown.styles fail to load. The browser attempts to resolve the virtual vscode-resource.vscode-cdn.net domain via DNS instead of intercepting it via the Service Worker, resulting in NS_ERROR_UNKNOWN_HOST.
This issue is specific to Firefox and its implementation of Service Worker / iframe isolation (dFPI).
Looks close to #7892 … BUT!!! The same setup works for me perfectly in Chromium-based browsers.
So I hope some workaround (custom settings, hacks) exists that can make work it with Firefox.
Steps to Reproduce
-
Run
code-serverand access it via Firefox. -
In a workspace, create a file
test.cssin the root directory. -
Add the following to
.vscode/settings.json:{ "markdown.styles": ["test.css"] } -
Open any
.mdfile and open the Markdown Preview. -
Check the developer tools Network and Console panels.
Expected
The Service Worker intercepts the request for test.css and serves the local workspace file, applying the custom styles to the preview (as it does in Chromium).
Actual
The preview renders without the custom CSS. In the Developer Tools Console:
Could not load 'markdown.styles': test.css
In the Network panel, the request for test.css fails:
- Host:
vscode-remote+<punycode>.vscode-resource.vscode-cdn.net - Error:
NS_ERROR_UNKNOWN_HOST - DNS Resolution: System
Investigation Details
Based on HAR exports and console logs:
- The Service Worker is registered and active.
- Extension resources inside the webview (e.g.,
index.bundle.jsfrom extensions) are successfully intercepted and returnHTTP/2 200. - However, the dynamically injected
<link rel="stylesheet">formarkdown.stylesbypasses the Service Worker and goes directly to the network. - Setting
privacy.partition.serviceWorkerstofalseinabout:configcompletely breakscode-serverinitialization (Error: IndexedDB database 'vscode-web-db' is closed), so it cannot be used as a workaround.
It appears to be a race condition or a cross-origin iframe isolation bug specific to Firefox, where the Service Worker fails to control the CSS fetch request initiated by the Markdown preview webview.
Attachments
Please find the attached console.log and .har (har.zip) network export demonstrating the bypassed Service Worker.
console-export-2026-7-30_12-31-17.log
xn--80ach2ae.xn--80apqgfe.xn--p1ai_Archive [26-07-30 12-32-00].har.zip
Logs
Screenshot/Video
No response
Does this bug reproduce in native VS Code?
Yes, this is also broken in native VS Code
Does this bug reproduce in VS Code web?
Yes, this is also broken in VS Code web
Does this bug reproduce in GitHub Codespaces?
Yes, this is also broken in GitHub Codespaces
Are you accessing code-server over a secure context?
- I am using a secure context.
Notes
No response
Activity
linear-code commentedon Jul 30, 2026
DEVEX-701
wingsuitist commentedon Oct 16, 2026
Possibly related data point: on Firefox ESR 140.17.0esr, every webview in code-server stays blank for us, not just the Markdown CSS. The webview's own
<script src>fails with the same error:The webview service worker (
pre/service-worker.js) is registered and active. Afetch()of the same URL from the outerpre/index.htmlframe returns 200 via the service worker. The request from the inner frame skips the service worker and goes to real DNS.Setup (clean, to rule out our environment):
--auth none, fresh--user-data-dirand--extensions-dir127.0.0.1(no proxy)Also blank on code-server 4.133.0. The built-in Markdown preview is affected the same way on ESR 140.17.
Note for anyone reproducing: under WebDriver (Selenium/geckodriver) ESR 140.17 renders fine. Playwright's Firefox build fails even where stock Firefox 158 works. Only a manually started browser showed the real behaviour.
Workaround for us: switched our images from
firefox-esrto the Firefox release from Mozilla's APT repository.