flutter test --platform chrome hangs/fails on Windows: CanvasKit assets 404 due to backslash path from path.fromUri

`flutter test --platform chrome` hangs/fails on Windows: CanvasKit assets 404 due to backslash path from `path.fromUri`

Summary

On Windows, flutter test --platform chrome fails for every web test (not just widget tests — a bare test() with no rendering fails identically) because the local CanvasKit-serving handler in flutter_tools builds a filesystem-style path from the request URL and then compares it against a hardcoded forward-slash prefix. path.fromUri returns a backslash-separated path on Windows, so the comparison never matches, every CanvasKit asset request 404s, the Flutter web engine's bootstrap throws an uncaught TypeError, and the test harness never reports a result — so the CLI either fails fast with a generic "Connection closed before test suite loaded" or hangs indefinitely, depending on timing.

Steps to reproduce

On Windows, with Chrome installed, create a brand-new project:
```
flutter create canvaskit_repro
cd canvaskit_repro
```
Run the default generated test on Chrome:
```
flutter test --platform chrome
```

No changes to pubspec.yaml, test/widget_test.dart, or any other generated file are needed — this reproduces with the completely unmodified output of flutter create.

Expected behavior

The default counter-app widget test passes on the chrome platform, as it does on vm/other platforms.

Actual behavior

The command either:

fails within about a second with:

00:00 +0: loading test\widget_test.dart
00:00 +0 -1: loading test\widget_test.dart [E]
  Failed to load "test\widget_test.dart": Connection closed before test suite loaded.
00:00 +0 -1: Some tests failed.

or hangs indefinitely with no further output once Chrome has been launched ([CHROME]: DevTools listening on ws://...).

Both are the same underlying failure; which one you see depends on the exact timing of the browser's WebSocket teardown after the uncaught exception below.

Root cause (found via live Chrome DevTools Protocol inspection)

Attaching to the running Chrome page via CDP (Runtime.enable / Log.enable) while the command is stuck shows the actual in-page failure, which the flutter test CLI never surfaces:

Log.entryAdded (network, error): Failed to load resource: the server responded with a status of 404 (Not Found)
  url: http://localhost:<port>/canvaskit/chromium/canvaskit.wasm
Log.entryAdded (network, error): Failed to load resource: the server responded with a status of 404 (Not Found)
  url: http://localhost:<port>/canvaskit/chromium/canvaskit.js

Runtime.exceptionThrown (Uncaught in promise):
  TypeError: Failed to fetch dynamically imported module: http://localhost:<port>/canvaskit/chromium/canvaskit.js

flutter_test always bootstraps the rendering engine — including CanvasKit — even for a test that never pumps a widget, so this 404 is fatal for every web test on Windows, not only widget tests.

The files genuinely exist in the SDK cache (confirmed present at <flutter>/bin/cache/flutter_web_sdk/canvaskit/chromium/canvaskit.js and .wasm), so this is a request-routing bug, not a missing/corrupt cache.

The bug is in packages/flutter_tools/lib/src/test/flutter_web_platform.dart, _localCanvasKitHandler:

shelf.Response _localCanvasKitHandler(shelf.Request request) {
  final String fullPath = _fileSystem.path.fromUri(request.url);
  if (!fullPath.startsWith('canvaskit/')) {
    return shelf.Response.notFound('Not a CanvasKit file request');
  }
  ...

_fileSystem.path is a package:path Context whose default Style is Style.windows on Windows, so .fromUri() on a URL like /canvaskit/chromium/canvaskit.js returns canvaskit\chromium\canvaskit.js — a backslash-separated string. The very next line checks fullPath.startsWith('canvaskit/') with a hardcoded forward slash, which never matches a backslash-separated path. Every CanvasKit asset request therefore falls through to Response.notFound, regardless of whether the file exists.

The comment directly above this function is telling:

/// Serves a local build of CanvasKit, replacing the CDN build, which can
/// cause test flakiness due to reliance on network.

— the intent is precisely to make this reliable/non-flaky, but the Windows path-separator mismatch defeats it entirely on this platform.

Suggested fix

Compare against the URL's own path segments instead of a platform-dependent filesystem path, e.g.:

shelf.Response _localCanvasKitHandler(shelf.Request request) {
  if (request.url.pathSegments.isEmpty || request.url.pathSegments.first != 'canvaskit') {
    return shelf.Response.notFound('Not a CanvasKit file request');
  }
  final String relativePath = request.url.pathSegments.skip(1).join('/');
  ...

(Uri.pathSegments is always forward-slash-delimited regardless of host OS, and _canvasKitFile/_fileSystem.path.join already correctly build the on-disk path from relativePath using the platform-appropriate path.Context — only this one comparison and the subsequent replaceFirst('canvaskit/', ...) need to stop assuming a forward-slash string.)

Additional, separate observation (not root-caused to an exact line — only reachable once the above is fixed)

A test file addressed by a path with subdirectories (e.g. test/features/auth/some_test.dart) fails a second, different way once the CanvasKit issue above is worked around: the DDC module loader reports

DartError: Exception: Web test for featuresauthsome_test.dart not found

— its path separators appear to be stripped somewhere in the test-name-to-module resolution. This may be a related manifestation of the same class of bug (a forward-slash assumption meeting a Windows backslash path) elsewhere in the same file/toolchain, but I have not traced it to an exact line and am not including a minimal repro for it in this report — flagging it in case it's useful context for whoever looks at the CanvasKit issue above.

Environment

[✓] Flutter (Channel stable, 3.47.5, on Microsoft Windows [Version 10.0.19045.7727], locale en-US) [609ms]
    • Flutter version 3.47.5 on channel stable at C:\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 6a19cca564 (2026-09-17)
    • Engine revision af7e796e16
    • Dart version 3.13.4
    • DevTools version 2.60.0

[✓] Windows Version (10 Enterprise 64-bit, 22H2, 2009)

[✓] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[✓] Connected device (3 available)
    • Chrome (web) • chrome • web-javascript • Google Chrome 154.0.8037.58

I also tried flutter test --platform chrome --wasm as a possible side-step (a different compile target); it fails the same way, so it is not a workaround.

@jahvari

Thanks for reporting @jahvari .

This is the same issue as #192069, which was closed as invalid because flutter test --platform chrome is deprecated in favor of flutter test -d chrome (see #162798). Your report covers only --platform chrome (and --platform chrome --wasm), which are the deprecated path.

Does it also reproduce with the supported command, flutter test -d chrome? If it does, this is a real bug on the supported path and we will route it to the web team. If -d chrome passes, this duplicates #192069 and the fix is to stop using the deprecated flag.

Thanks for the quick reply! You're right: I retested with flutter test -d chrome on the same Windows machine and repro (Flutter 3.47.5), and it passes fine. Only the deprecated --platform chrome hangs. So this is a duplicate of #192069. We'll switch over to -d chrome. Closing this out, and thanks for pointing us in the right direction!

Apologies, I closed this too quickly. After more testing, I don't think -d chrome is a replacement for --platform chrome: it doesn't run widget tests in a browser at all. It runs them on the Flutter Tester (the VM), so my earlier "it passes" was a VM pass and didn't prove anything.

What I tested (Flutter 3.47.5 stable, Dart 3.13.4, Chrome 154, using two tests that can only pass inside a real browser):

// test/where_test.dart
test('runs inside a browser', () {
  print('PROBE kIsWeb=$kIsWeb');
  expect(kIsWeb, isTrue);
});

// test/browser_api_test.dart (imports package:web)
test('can read the browser user agent', () {
  print('PROBE userAgent=${web.window.navigator.userAgent}');
  expect(web.window.navigator.userAgent, contains('Chrome'));
});

Command	OS	Result
`flutter test -d chrome test/where_test.dart`	Windows	Runs in `flutter_tester` and no Chrome is launched. `kIsWeb=false`, test fails
`flutter test -d chrome test/browser_api_test.dart`	Windows	Doesn't compile: `dart:js_interop` is not available on this platform
`flutter test integration_test/where_test.dart -d chrome`	Windows	`Web devices are not supported for integration tests yet.`
`flutter test --platform chrome test/`	Windows	Hangs at `loading`; killed after 188 s
`flutter test --platform chrome test/`	Linux (Debian, Chromium 154)	Both pass: `kIsWeb=true`, user agent `HeadlessChrome/154.0.0.0`
`flutter test -d chrome test/where_test.dart`	Linux	VM again: `kIsWeb=false`, test fails

This matches the tool's source. packages/flutter_tools/lib/src/commands/test.dart says tests under test/ run in the Flutter Tester ("a desktop-based Flutter embedder"), and it only reads -d for integration tests, which reject web devices. So, as far as I can tell, --platform chrome is currently the only way to run flutter_test suites in a browser. The same question was asked on #162798 (#162798 (comment)) and went unanswered before that thread locked.

Why --platform chrome hangs on Windows: I attached to the headless Chrome over the DevTools protocol while it was stuck. The test server returns 404 for the CanvasKit files, so the engine never starts and the runner waits forever. The files exist in bin/cache/flutter_web_sdk/canvaskit/chromium/. The cause is the check in _localCanvasKitHandler (packages/flutter_tools/lib/src/test/flutter_web_platform.dart:519-520): path.fromUri(request.url) gives canvaskit\chromium\canvaskit.js on Windows, so startsWith('canvaskit/') is false.

Log excerpts

-d chrome on Windows (verbose log mentions only flutter_tester, no chrome.exe):

PROBE kIsWeb=false defaultTargetPlatform=TargetPlatform.android
  Expected: true
    Actual: <false>
00:00 +0 -1: Some tests failed.

-d chrome with package:web on Windows:

.../pub.dev/web-1.1.1/lib/src/helpers.dart:24:8: Error: Dart library 'dart:js_interop' is not available on this platform.

--platform chrome in a Linux container:

PROBE kIsWeb=true defaultTargetPlatform=TargetPlatform.android
PROBE userAgent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/154.0.0.0 Safari/537.36
00:05 +2: All tests passed!

--platform chrome on Windows, captured from the hung headless Chrome after a reload:

404 text/plain http://localhost:58903/canvaskit/chromium/canvaskit.wasm
404 text/plain http://localhost:58903/canvaskit/chromium/canvaskit.js
TypeError: Failed to execute 'compile' on 'WebAssembly': HTTP status code is not ok
TypeError: Failed to fetch dynamically imported module: http://localhost:58903/canvaskit/chromium/canvaskit.js

I'm reopening this since the Windows bug still affects the only browser test path. If --platform chrome is going away, is there a supported way to run flutter_test suites in a real browser? I'm happy to test a fix on Windows.

@jahvari

Thanks for the detailed follow-up @jahvari.
Routing to team-windows for further investigation.

[flutter_tools] Fix local CanvasKit asset paths on Windows

[flutter_tools] Fix local CanvasKit asset paths on Windows (flutter#1…

The fix is being reverted due to a failure: #195635

Revert: [flutter_tools] Fix local CanvasKit asset paths on Windows (f…

[flutter_tools] Reland fix for local CanvasKit asset paths on Windows (…

Navigation Menu

Repository navigation

flutter test --platform chrome hangs/fails on Windows: CanvasKit assets 404 due to backslash path from path.fromUri #193505

`flutter test --platform chrome` hangs/fails on Windows: CanvasKit assets 404 due to backslash path from `path.fromUri`

Summary

Steps to reproduce

Expected behavior

Actual behavior

Root cause (found via live Chrome DevTools Protocol inspection)

Suggested fix

Additional, separate observation (not root-caused to an exact line — only reachable once the above is fixed)

Environment

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

flutter test --platform chrome hangs/fails on Windows: CanvasKit assets 404 due to backslash path from path.fromUri #193505

Description

flutter test --platform chrome hangs/fails on Windows: CanvasKit assets 404 due to backslash path from path.fromUri

Summary

Steps to reproduce

Expected behavior

Actual behavior

Root cause (found via live Chrome DevTools Protocol inspection)

Suggested fix

Additional, separate observation (not root-caused to an exact line — only reachable once the above is fixed)

Environment

Activity

mbcorona commented on Sep 29, 2026

jahvari commented on Sep 29, 2026

jahvari commented on Sep 30, 2026

mbcorona commented on Oct 3, 2026

3 remaining items

mdebbar commented on Oct 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`flutter test --platform chrome` hangs/fails on Windows: CanvasKit assets 404 due to backslash path from `path.fromUri`