1210976 - Make the detail level of resource types exposed to WebExtensions WebRequest discoverable

Status: RESOLVED DUPLICATE of bug 1209983

(WebExtensions :: Untriaged, defect, P3)

Description

[Giorgio Maone [:ma1]]

Bug 1209983 may cause incompatibilities with Chromium add-ons which rely on a coarser resource types set.
Also, nsIContentPolicy has a long story of adding new load types over the time, which can be easily discovered because they are exposed as interface constants:

if ("TYPE_XBL" in Ci.nsIContentPolicy) doSomething();

Therefore it might be desirable having a mean to know which resource types are currently supported, for instance by querying an immutable static Set property of WebRequest:

if (chrome.webRequest.resourceTypes.has("xbl")) doSomething();

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I think in Chrome you can already query chrome.webRequest.ResourceType, which is (strangely) an object of this form:
{"MAIN_FRAME": "main_frame",
 "SUB_FRAME": "sub_frame",
  ...}
I think we'll just implement that (despite the odd capitalization).

Comment 2

[Giorgio Maone [:ma1]]

(In reply to Bill McCloskey (:billm) from comment #1)
> I think in Chrome you can already query chrome.webRequest.ResourceType,
> which is (strangely) an object of this form:
> {"MAIN_FRAME": "main_frame",
>  "SUB_FRAME": "sub_frame",
>   ...}
> I think we'll just implement that (despite the odd capitalization).

Not so odd, maybe: I think they're trying to mimic an enum, like

if (e.resourceType === ResourceType.MAIN_FRAME) doSomething();

If that's the meaning, you should probably use those "constants", instead of string literals, in your code and in the API docs as well.

Comment 3

[Tom S. (please needinfo tschuster)]

I guess this is fixed by https://hg.mozilla.org/integration/mozilla-inbound/rev/bb924113e8c6 (bug 1209983)