(In reply to Julian Descottes [:jdescottes] from comment #4)
Hi Luca, could you share a summary of the main blockers for this work?
I think we discussed it previously but I can't find the outcome anymore.
yeah, I also recall that we discussed about it before, but I've looked briefly for an email thread or shared document about it but I couldn't find any.
Anyway, the following should be a summary of the current status and some of the blockers that I recall right now:
The DevTools APIs themselves (like
devtools.inspectedWindow.eval etc.) should be using the remote debugging protocol to reach and interact with the devtools target, and so part of what we need to make them work on a remote target should be already there.
Nevertheless, the remote target was a "non-supported scenario" and so it isn't tested as part of the automation (in same case we may be even testing the opposite, like that the extension isn't able to attach a non supported toolbox or interact with a non supported target), and so there are definitely details that we need to change (or re-design) or changes applied in the meantime that may be assuming that the target is always a local tab.
As an example, the following ones falls under that category:
ext-devtools.js / ext-devtools-panel.js are actively ignoring or rejecting targets that are not local tabs:
devtools.inspectedWindow.tabId is supposed to be the
tabId of the target, the same
tabId that would allow the extension to interact with the tab using the
tabs API, and so this spawns some additional design questions:
- what should the
tabId be for a remote target? (and what if the remote target is not a tab?)
- what is the extension be able to do with that id? (the
tabs API wouldn't be able to interact with a remote tab, and so should we provide a subset of what they may want to do through a
devtools API namespace instead?)
- how we let the extension know that the target is remote? (e.g. it could be a separate devtools.inspectedWindow.isRemoteTarget property)
devtools.inspectedWindow.eval is handled by an RDP actor, but it wouldn't currently work if the extension isn't also available on the remote target side because the actor looks for the WebExtension policy object to be able to check if that extension should be able to evaluate js code on the target, e.g. see:
Follows some additional side notes:
Existing third party devtools webextensions vs. remote targets
The existing devtools webextensions (at least the ones that I looked into in the past, like the Redux or the React DevTools, and the Ember Inspector) are often also using a content script to attach the webpage and then sending messages to the extension devtools panel when something relevant is happening into the page (basically the extensions are often "actively pulling data from the page" using devtools.inspectedWindow.eval and "passively receiving data from the page" from the content script emitted messages), and there isn't currently an existing way to achieve that for a remote target and so those extension are not going to be able to work completely as is.
We have to design a "remote targets"-compatible solution to make the devtools extensions able to "passively receiving data from a remote page", as an example one idea could be to:
- have the same extension installed in both the local and remote targets
- and expose a new API event from the devtools namespace to subscribe a listener to be called when a message is emitted by the extension on the connected remote side
Remote targets and extension "privilege levels"
If we do allow the extensions to hook their devtools_page to a toolbox opened for a remote target, then we will also have to look into the kind of remote target and the "privilege level" of the extension, to ensure that the extensions are going to be able to reach only remote targets with a lower or equal "privilege level".
As an example:
- we should only allow privileged extensions to be able to work on a remote target that has chrome privileges
- third party extensions should only be able to attach remote tab targets related to content webpages (and not "privileged tabs" like about:addons, about:config etc.)
- in some cases we may also want to leave the user to choose (e.g. if allowing a third party extension or not to interact with a remote webextension target)