1304378 - Support DevTools Addons on developer toolboxes connected to remote tabs

Status: NEW

(WebExtensions :: Developer Tools, defect, P3)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

The initial version of the DevTools API is going to support the customization of developer toolboxes connected to a local tab (the regular developer toolbox available for webpages loaded in a local Firefox tab).

The goal of this issue is to analyze the additional issues (and the  changes needed) related to make the DevTools Addons created using the WebExtensions API able to support customizations of developer toolboxes connected to remote targets (in particular tabs opened on Firefox for Android).

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

:mstange and I discussed something similar a few months ago, and I filed bug 1351533 to do the minimum work of exposing WebIDE's runtime data for a connection.  It wouldn't be accessible to a WebExtension, but perhaps this bug might want something similar.

Comment 2

[Markus Stange [:mstange]]

We'll want to use the runtime data exposed by bug 1351533 for the internal implementation of the remote profiler WebExtension API in bug 1371003: The profiler API has a way to ask for symbol tables, and in order to get that symbol information, we'll need to pull libraries from the device.

Comment 3

[Alex Thayer [:alexical] (she/her)]

How far do we want to go on this? I'm interested in it purely for the Gecko Profiler, which just needs to make a panel and then use some APIs that aren't made yet, but nonetheless I have a patch ready that implements everything other than tabId. tabId is tricky because at that point everything else outside of devtools that uses tab IDs needs to be capable of interacting with remote tabs. For this reason I separated out devtools_page from a remote_devtools_page, so that remote tab access is opt-in, so as to not break any assumptions of existing extensions.

Comment 4

[Julian Descottes [:jdescottes]]

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.

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

(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:

  • https://searchfox.org/mozilla-central/search?q=target.isLocalTab&case=false&regexp=false&path=components%2Fextensions

• 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:

  • https://searchfox.org/mozilla-central/rev/1fe0cf575841dbf3b7e159e88ba03260cd1354c0/devtools/server/actors/addon/webextension-inspected-window.js#508-515
  • https://searchfox.org/mozilla-central/rev/1fe0cf575841dbf3b7e159e88ba03260cd1354c0/devtools/server/actors/addon/webextension-inspected-window.js#546-579

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)