1453343 - browser.tabs is undefined in panel created by devtools.panels.create.

Status: NEW

(WebExtensions :: Developer Tools, enhancement, P3)

Description

[Blake Winton (:bwinton) (:☕️)]

I checked browser/components/extensions/test/browser/browser_ext_devtools_panel.js and there aren't any tests for this.

https://developer.chrome.com/extensions/devtools_panels#overview says:
> All extension pages displayed in the Developer Tools window have access to all modules in chrome.devtools API, as well as to chrome.extension API. Other extension APIs are not available to the pages within Developer Tools window, but you may invoke them by sending a request to the background page of your extension, similarly to how it's done in the content scripts.

so according to the spec we shouldn't implement this, buuuuuttttt the code works in Chrome, so by following the spec we're incompatible in a kind of confusing way, as shown in https://github.com/ireade/feature-queries-manager/issues/1

I'll leave it up to someone else to figure out whether we should change our implementation or add some more documentation. ;)

Comment 1

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

In Firefox we already run the devtools page and devtools panels in the separate extension process (where the oop extension mode is enabled) and we enforced the "limited APIs available" behavior only for "chrome-compatibility" reasons.

And so we can change definitely plan to apply the same change as well, and I think that we should, because (as described below in the detailed part of this comment) both Chrome/Chromium and Opera do not have this limitation in place anymore.

(and update our docs / communicate it to the addon developers so that the new behavior is not going to be surprising, e.g. the devtools page and panels are going to be able to receive the extension messages sent from the content scripts again, which we prevented explicitly on Firefox 57 in Bug 1383310 because it was surprising and, more important, the devtools panel could not reply to the content script because the tabs API wasn't available).

----

Some additional notes about this (mainly for historical reasons):

The unexpected (and undocumented) change of behavior in recent Chrome versions seems likely to be a side effect of the "--isolate-extensions" option graduated to become the Chromium default instead of an experimental behavior enabled only when the options is specified on the command line 

https://bugs.chromium.org/p/chromium/issues/detail?id=550151 contains some additional details about a similar change in behavior noticed on the extension pages loaded inside sub-frames of a regular webpage, which has been wontfix-ed because (even if it was initially an unexpected side-effect) they have decided that it was a desirable change.

The above issue doesn't mention the devtools page or panels explicitly, but I've briefly tried on a chromium version that I have locally (which is the version 65) and the devtools panel definitely had access to the tabs API (which means that the old "limited APIs available" behavior is not there anymore, by default).

The github issue linked in comment 0 also mention Opera, and so I was curious and I tried it also on Opera:
Opera 50 didn't have the chrome.tabs API namespace available in the devtools page/panels (it was the version I had already installed locally), but the last version (Opera 52) does have the tabs API in the devtools page/panels, and so it looks that they also got the new behavior as soon as they updated their chromium fork to a more recent one, that already had the new behavior enabled.

Comment 2

[Tomislav Jovanovic :zombie]

In order to simplify things about the messaging mess, I'm probably changing devtools contexts to receive message from content scripts in bug 1583484, so we should probably also change this behavior in the same firefox release.

Luca, can you please write a brief summary of what needs to be done here to expose full extension APIs to devtools contexts?

Comment 3

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

Follows a list of what needs to be done (I briefly double-checked these on searchfox and it should still be quite complete):

• the devtools_child/devtools_parent env types are not currently listed in the scopes API registration property related to a number of API modules, and so we'll need to apply changes to the related files (which should be ext-browser.js, ext-browser.json, ext-toolkit.js, ext-toolkit.json)

• the extensions' devtools page and devtools panel contexts use a separate SchemaAPIManager instance named devtoolsAPIManager (and defined here](https://searchfox.org/mozilla-central/rev/723e61e5f6fe36e69592b7742bc10338392e53e4/toolkit/components/extensions/ExtensionPageChild.jsm#140-157)), it also likely needs some changes to make sure that we will also provide access to the other APIs available to the other extension pages

• a good chunk of the changes originally introduced to prevent the content scripts message and ports to be received from the devtools pages (landed from Bug 1383310) has to be reverted (e.g. in particular the ones applied to the Messenger class, looking on searchfox for bug 1383310 and/or for this.excludeContentScriptSender should point us directly to them)

• some test cases (introduced by Bug 1383310) are currently checking that a devtools context doesn't receive messages and ports from a content script, and so we will need to change them to actually cover the new expected behavior (If I recall correctly the only test case should actually be this one)

Comment 4

[Jethro Nederhof]

Similarly, chrome.permissions/browser.permissions is undefined in the DevTools panel context in Firefox, but not Chromium.

Should Chrome incompatibilities be updated to include this difference in behaviour? My extension using chrome.tabs & chrome.permissions in a DevTools panel context works fine in Edge, Chromium, and Chrome; Firefox is the only outlier but there's no mention of APIs being completely unavailable in certain contexts vs those other browsers.

I noticed permissions missing before tabs, because the flow is to permissions.request and then use tabs.get to get the devtools.inspectedWindow.tabId tab so I can get its window and drawAttention/focus it so the user can see the prompt when DevTools is in an undocked window. Thought I'd mention permissions missing explicitly since this issue didn't show up easily when searching for permissions being undefined.