`webRequest.ResourceType` and `declarativeNetRequest.ResourceType` for text module imports

[eemeli]

The HTML and Fetch standards have been updated to add support for text imports, as in:

import text from "./path/to/file.txt" with { type: "text" };

The Fetch standard update includes a new destination "text" for such imports, which is then made available to servers via a Sec-Fetch-Dest: text header.

While reviewing my Firefox implementation for this, @Rob--W identified that the web extension webRequest.ResourceType and declarativeNetRequest.ResourceType also need consideration, and might warrant either adding a new text type there as well, or using other instead. Which one should we go with?

As potentially relevant context, it's likely that the import-bytes proposal will also be advancing in the relevant standards bodies, at least once immutable arraybuffers become available. That'd add { type: "bytes" } import attribute support. I'm not aware of any other new module types being advanced at the moment.

[Rob--W]

Relevant ResourceType docs:

• https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/ResourceType
• https://developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest#type-ResourceType
• https://developer.chrome.com/docs/extensions/reference/api/webRequest#type-ResourceType

For further context, Firefox has already added the "json" type for json imports (where Chrome used "script") (last time I checked: https://phabricator.services.mozilla.com/D229524#inline-1280484 )

For css imports, Firefox uses the existing "stylesheet" ResourceType.

Chrome also specifies "webtransport" and "webbundle", for which Firefox uses "other".

A general question to ask is whether we want to match the web's definition of "destination" for ResourceType where possible (except for existing ones to retain backwards compatibility) instead of making case by case decisions. The web's "destination" values are documented at https://developer.mozilla.org/en-US/docs/Web/API/Request/destination

[Rob--W]

Use "other" as the ResourceType for now, until use cases arise that warrant further distinction.

"xmlhttprequest" (historical name, same purpose as fetch) was also voiced as an option, since web sites would likely use fetch() as an alternative.

[oliverdunk]

I spoke to Devlin about this. In Chrome, it seems like we still use script for JSON imports. We don't have a strong view on this behavior (or the behavior for text imports) other than wanting to avoid adding new enum variants if we can.

Moving forward with other as Rob suggested SGTM.