1852126 - Cannot debug iframe in extension sidebar

Status: NEW

(WebExtensions :: Developer Tools, defect, P3)

Description

[Diggory]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

• Create an extension with a sidebar
• Put an iframe pointing to any website in the sidebar
• Run firefox with the extension
• Open the extension's sidebar
• Go to about:debugging and inspect the extension
• Click the button in the top-right with the tooltip "Select an iframe as the currently targeted document"

Actual results:

The dropdown lists the extension's background page and the sidebar page, but does not list the iframe inside the sidebar.

Expected results:

It should be possible to select the iframe inside the sidebar.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

Would you be able to attach an example extension demonstrating the issue? Thank you !

Comment 3

[Diggory]

Attachment: sample-extension.zip

I've added an example extension - it must be loaded via Load Temporary Add-on in about:debugging.

Comment 4

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

The issue here seems to be due to the fact that the iframe included in the extension page loaded in the sidebar is a webpage from an https url (wikipedia in the attached example).

That kind of frame should be matching the check isExtensionWindowDescendant here in the WebExtensionTargetActor: webextension.js, which is calling out this scenario explicitly too:

// Check if the source is coming from a descendant docShell of an extension window.
// We may have an iframe that loads http content which won't use the add-on principal.

But I think that was going to work before fission, but that after fission it may not be working anymore and should be replaced with some other check that would be working in a fission enabled instance (where the web frame nested into a webextension page may even be running in a different child process).

I'll dig a bit more into it and gather some more details, then we may move this in the DevTools components or needinfo a DevTools engineer to get some perspective from their side and help to determine the right way to fix it.

Workaround: accessing the nested iframe from the Browser Toolbox in Multiprocess mode

In the meantime I wanted to mention that as a workaround, an extension developer can still reach the nested iframe through the Browser Toolbox debugging window (after switching it to Multiprocess mode, so that the frame selector included in that devtools window will be able to see every frame running in any of the Firefox child processes, included the extension pages and webpage frames nested into extension pages).

Comment 5

[Alex Cornestean]

Hello and thank you for the sample extension !

I reproduced the issue on the latest Nightly (119.0a1/20230911154121), Beta (118.0b7/20230910175934) and Release (117.0/20230824132758) under Windows 10 x64 and Ubuntu 22.04 LTS.

The issue occurs as described in the “Actual” section of Comment 0. For more details, see the attached screenshot.

Comment 6

[Alex Cornestean]

Attachment: 2023-09-12_09h54_02.png

Comment 7

[Alexandre Poirot [:ochameau]]

Bug 1754452 significantly changed how to consider each document to be part of an add-on or not, but we still can't debug that wikipedia iframe.
The check is still addonId based:
https://searchfox.org/mozilla-central/rev/f53c09a22edc700ab1a9eaaf4da0f0dd9f11bff3/devtools/server/actors/watcher/browsing-context-helpers.sys.mjs#204
https://searchfox.org/mozilla-central/rev/f53c09a22edc700ab1a9eaaf4da0f0dd9f11bff3/devtools/server/actors/watcher/browsing-context-helpers.sys.mjs#25-58

We may try to check the addonId of the top browsing context of the given window global, instead of the immediate principal of the window global.

Comment 8

[Alexandre Poirot [:ochameau]]

Unfortunately accessing the top browsing context from isBrowsingContextPartOfContext, via windowGlobal.browsingContext.top returns a cross process BrowsingContext interface, which prevents retrieving the current browsing context principal (we are using windowGlobalChild.documentPrincipal or browsingContext.window.document.nodePrincipal, which are both not working on cross process browsing contexts).
AFAIK, the document principal is the only interface exposing the addonId with the BrowsingContext/WindowGlobal universe.

The only way out of this would be to use something else than addon id to detect the documents to debug.
But I think they all have caveats:

• browserId. There would be many <browser> elements, so that is not suitable.
• browsingContextGroupID. That may be out best option, but the fact that this ID changes on add-on reload is an issue.

Things would be significantly simpler if the addonId could be part of origin attributes.

Luca, do you think that would be possible to expose addonId on all web extension browser elements? Or make the browsingContextGroupID stable across addon reload? Or any guess of other attribute we could use to easily detect all browsing-context/window-global related to a given add-on?