GetPreferredExtensionForMimeType() first calls GetPlatformPreferredExtensionForMimeType(), which calls into the platform to get the extension it prefers.  So presumably recent versions of Windows 10 associate weba with "audio/webm".

So we either need to modify the test to allow both, or disable the test / remove that test case.  I suppose we could also either deprioritize the platform's preferred extensions for each MIME type, or remove the call into platform code entirely, though I'm not sufficiently familiar with the motivation to use a platform API here (on OSX and Windows, at least), to make that call.

[asanka]:  Thoughts?

Thanks for catching this. I'd be okay with removing the test case if we are seeing a variance in platform behavior here.

Can we identify what changed and why this test isn't failing on the Win 10 bots? If .weba is a common default, then we should add it as a secondary mapping so that consumers of //net can correctly assign a MIME type to .weba files when no other MIME type hints are available.

The bots may not be using an up-to-date image of Windows.  I can repro the failure both on my home and corp machines.

Gotcha. In that case I'd suggest:

  * Remove that test case.
  * Add a secondary file extension mapping for "audio/webm" -> "weba" along with a comment on where this was commonly observed.
  * Add a test for mapping file extension "weba" -> "audio/webm".

In general an OS change like this will permeate across the internet pretty quickly.