Open Bug 1361121 Opened 3 years ago Updated 2 months ago

Implement devtools.inspectedWindow.getResources


(WebExtensions :: Developer Tools, enhancement, P3)



(Not tracked)


(Reporter: clarkbw, Unassigned)


(Depends on 1 open bug, Blocks 1 open bug, )


(Keywords: dev-doc-needed, Whiteboard: [devtools, triaged])

I couldn't find a bug related to this exact API so figured I'd file one.

According to this API is not yet supported.

The Redux DevTools extension currently uses this API to determine if the URL was loaded from the file:// scheme and warn the user that there is a special checkbox required to click in Chrome.

I think we might be able to guard against this check for Firefox to work, seeing as Fx doesn't have this requirement; so stay tuned.
Not sure if this should block bug 1211859 so adding this to the see also for now.
See Also: → 1211859
I was able to work around this API call in Firefox for the Redux DevTools
Priority: -- → P3
Whiteboard: [devtools, triaged]
I can not implement the extension Html Validator correctly because this API is missing. I have no other way to get the HTML source sent by the server..

The same works in Chrome.

Can we increase this problem to P2 ? There is no perfect work-around. I get regularly email about it. People do not understand that reading HTML source via DOM is not identical that reading the HTML sent by the server.

See Also: → 1461633
Product: Toolkit → WebExtensions

I'm using this API method in a devtools extension that disables CSS features for testing progressive enhancements/fallbacks (

Despite requests for Firefox support, I'm having to tell users that it isn't possible right now because Firefox doesn't implement the API methods needed to work with resources.

Is there any news on this?

Hi Keith, your addon looks great, and I'd love for Firefox to be able to support it.

bug 1461633 comment 1 brings context as to why this API method is on hold for now. In short, we'd need to refactor quite an important part of DevTools itself for this API to be doable. I'm asking around right now to know if such a refactor can be on the current roadmap or not.

In the meantime, I'd like to bring your attention to this other similar addon: which works on Firefox.
And the piece of code that seems to be making the addon work on Firefox without needing getResources:

I don't know if an approach like this could work for you?
I think it shouldn't be too hard to list the stylesheets using document.stylesheets instead of getResources, but rewriting stylesheets without using resource.setContent would be harder, and using deleteRule/insertRule instead might mean having to change your regex-based stylesheet rewriting logic.

Flags: needinfo?(keith)

(In reply to Patrick Brosset <:pbro> from comment #6)

bug 1461633 comment 1 brings context as to why this API method is on hold for now. In short, we'd need to refactor quite an
important part of DevTools itself for this API to be doable. I'm asking around right now to know if such a refactor can be
on the current roadmap or not.

So, turns out that yes, we might be working on the mentioned DevTools refactor at some stage in the future. But I don't have a date for this yet.

Hi Patrick

I can see that this would be a big chunk of work but — reading bug 1461633 comment 1 — it looks like devtools would benefit from the implementation.

In the case of my extension, I did experiment with iterating over document.stylesheets and extracting the css rules but, while that approach did appear to work in all browsers, I ran into issues accessing the content of a stylesheet when served from a different origin to that of the document.

Reading and writing style rules through the CSSOM would actually be preferable as using regexes on the result of resource.getContent() is pretty fragile — however, the current approach does work for every stylesheet.

Flags: needinfo?(keith)

Thanks for getting back to me Keith.
The cross-origin stylesheets is a good point indeed.

You are right, DevTools would benefit from such a centralized resource listing mechanism, and we might implement it sooner rather than later. But that is still unknown unfortunately.

The only other option I can think of is exposing a new experimental WebExtension API.
The way this works is you create sort of a separate addon. Its job is only to expose a WebExtension API. But it can do this by accessing a lot of Firefox internals. So, for instance, it could use Firefox super powers to list all stylesheets, without having to worry about cross-origin. And it could then write back to them by using Firefox-only APIs like InspectorUtils.parseStyleSheet(sheet, text).
It would hide all of this internal code behind a new WebExtension API. Your actual addon could then make use of this API as if it was an actual WebExtension API.
The only problem with this is this mechanism is limited to Nightly and DevEdition.

Anyway, I thought I'd share this. I don't have any other ideas after that :)
So if that's not a valid option for you, then we'd unfortunately just have to wait for the actual API to be implemented for real in Firefox.

Thanks for the suggestions Patrick.

Now I know that this is on the radar, I think there's mileage in exploring a same-origin limited version for which would kick-in if a feature test for getResources failed. At least that would allow Firefox users to access the extension in development environments (where CORS is controllable) until the actual API is implemented.

You need to log in before you can comment on or make changes to this bug.