[Firefox] Markdown Preview fails to load workspace CSS via markdown.styles (NS_ERROR_UNKNOWN_HOST for vscode-resource.vscode-cdn.net)
- Langage dominant
- TypeScript
- Étoiles
- 79.3k
- Forks
- 6.8k
- Merge moyen
- 2 j 6 h
- PR mergées (30 j)
- 41
Description
### Is there an existing issue for this?
- [X] 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 811ec6c1d60add2eb92446161ca812828fdbaa7f 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 coder/code-server#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
1. Run `code-server` and access it via Firefox.
2. In a workspace, create a file `test.css` in the root directory.
3. Add the following to `.vscode/settings.json`:
```json
{
"markdown.styles": ["test.css"]
}
```
4. Open any `.md` file and open the Markdown Preview.
5. 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:
```text
Could not load 'markdown.styles': test.css
```
In the Network panel, the request for `test.css` fails:
* **Host**: `vscode-remote+.vscode-resource.vscode-cdn.net`
* **Error**: `NS_ERROR_UNKNOWN_HOST`
* **DNS Resolution**: System
### Investigation Details
Based on HAR exports and console logs:
1. The Service Worker **is registered and active**.
2. Extension resources inside the webview (e.g., `index.bundle.js` from extensions) are successfully intercepted and return `HTTP/2 200`.
3. However, the dynamically injected `` for `markdown.styles` bypasses the Service Worker and goes directly to the network.
4. Setting `privacy.partition.serviceWorkers` to `false` in `about:config` completely breaks `code-server` initialization (`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
```shell
```
### 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*
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Reproduce the Markdown preview with markdown.styles set to test.css in Firefox, then inspect the Service Worker registration, Network panel, and console for the vscode-resource.vscode-cdn.net request. Done means workspace CSS is intercepted and applied in Firefox without breaking code-server initialization or IndexedDB.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- typescript
- Domaine
- frontend, web-dev
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Calme
- Clarté
- Plutôt claire
- Accessibilité débutants
- 42/100