The reason the existing tests are broken is that Web Speech API on Linux has a dependency on the network speech synthesis extension, which is turned off with the --test-type flag:
  // Component extensions with background pages are not enabled during tests
  // because they generate a lot of background behavior that can interfere.


 I wonder if we can turn on all default component extensions if --test-type=webdriver, otherwise we may need a specific flag. +tapted who added this caveat.

https://cs.chromium.org/chromium/src/chrome/browser/extensions/component_loader.cc?rcl=dadf2142b7db246fa9055a5943d1d9a5f14a287b&l=593

Yah - each component extension starts up it own render process shortly after chrome startup, unless the same Chrome version has run in this profile dir previously. That's a huge impact.

There are some ChromeOS tests that selectively enable component extensions -- https://cs.chromium.org/chromium/src/chrome/browser/chromeos/file_manager/file_manager_test_util.cc

If there's a specific extension you need, it might be better to load that rather than starting ~20 processes.

The file_manager tests have a long history of flakiness, and there's a lot of engineering effort spent to reduce the startup cost specifically for those.

Thanks tapted. Unfortunately since we want to enable these on WPT test / Layout tests, I'm not sure we can selectively enable these without adding additional command line flags.

+kereliuk: We spoke before about running some WPT tests with special command line flags. Do you think that would be possible to do without enabling the flag on the entire suite of WPT tests? I worry that in just getting a half dozen tests working we regress the entire performance of WPT due to needing a new extension proc.

+foolip FYI

The tests themselves in wpt I believe are actually valid-ish going by the spec, but something is definitely up as they don't run as expected on bots.

foolip: Are the failures explained by c#3 or are you seeing something else?

Another thing is that Speech API is implemented at the //chrome layer and so will not work (AFAIK) in content_shell.

csharrison@, what I've observed when writing new WPT tests is that after running them a few time they usually stop working, as if the speech engine is just not responding. I'm going to file a bug using one of the tests in https://github.com/web-platform-tests/wpt/pull/12992 (review appreciated!) once merged.

csharrison@, if you'd like to work on upstreaming existing tests, I'd be happy to review.

foolip: that smells like issue 768199 to me, which I've hit once or twice in local testing. Essentially the API just breaks for the entire duration of the browsing session. Maybe the word limit varies by platform.

Feel free to add me as a reviewer on the WPT PR.