Closed Bug 1780912 Opened 2 years ago Closed 2 years ago

Unable to inspect webextension popup

Categories

(DevTools :: Inspector, enhancement, P3)

enhancement

Tracking

(firefox106 fixed)

RESOLVED FIXED
106 Branch
Tracking Status
firefox106 --- fixed

People

(Reporter: krinkle, Assigned: ochameau)

References

(Blocks 2 open bugs, Regressed 1 open bug)

Details

Attachments

(3 files, 1 obsolete file)

Attached video Kapture.mp4

What were you doing?

Trying to use devtools on the HTML document that represents the webextension popup while it is visible. I'm basically following the MDN guide at

https://extensionworkshop.com/documentation/develop/debugging/
as promoted via
https://hoosteeno.com/2016/09/20/debugging-webextension-popups/

  1. Debug extension, leading to "Debugging - Runtime / this-firefox" page.
  2. Press "Inspect", leading to "Toolbox - Extensions / myextension" page which is a viewport-less page with the devtools open.
  3. Use three-dot menu to turn on "Disable Popup Auto-Hide".
  4. Engage with extension button to open popup.

What happened?

I am unable to switch the devtools from its default mode for background.html to popup.html, because all the following are true:

  • The devtools UI is behind the very popup I'm trying to inspect, whicih by default obscures the devtools UI button for toggling between background.html and popup.html.

  • The devtools UI when in toolbox mode, does not permit resizing the top (unlike on regular web pages) as in this mode there is no visual viewport above the devtools to negotiate space between. Very sensible, but this means vertical resize of devtools is not a solution to access devtools UI (e.g. make the devtools less tall, start further down).

  • The devtools UI is also horizontally snug to the main window, e.g. I also can't resize horizontally to have the devtools UI come out from under the popup.

  • The devtools button or switching modes is only visible when popup.html exists / is open, which means I cannot toggle when the popup is hidden, as the control is inactive during that time when there is no popup to choose. And even on rare cases where I beat the hiding of the UI control, it is a dropdown menu with only background.html as popup.html has already been removed again.

  • The devtools "dock left/right/separate window" (esp separate window) are not available in the extension toolbox mode.

  • The webextension implementation destroys the popup DOM when the popup is not open (presumed, not actually sure).

What should have happened?

If even one of the above were not true, I believe the issue would be resolved.

Anything else we should know?

The devtools "dock left/right/separate window" (esp separate window) are not available in the extension toolbox mode.

So I definitely agree the webextension toolbox is a pain, especially for popups. However, note that this toolbox lives in its own tab, and you can use your webextension from another window.

If you create a new window, and open the webextension popup from there, does it work for you?

Flags: needinfo?(krinklemail)

Thanks @jdescottes, that works for me!

Flags: needinfo?(krinklemail)

We have always been opening about:debugging toolboxes as tabs, but it might be a better fit to create new windows, without any of the usual chrome (no URL bar etc...). This way users would not get into the situation described here.

Or maybe that should at least be an option, to choose between opening in a tab or in a window.

Or we could emulate some "docking". The only options for those toolboxes would be "as a tab" or "as a window".

Type: defect → enhancement
Priority: -- → P3

This has been added many years ago when introducing side hosts.
We should now consider this a builtin feature.

Assignee: nobody → poirot.alex
Status: NEW → ASSIGNED

See bug 1732103 comment 6. It may simplify things around debugging web extension popups.
But it wouldn't address the issue of popups hidding a few devtools UI on the top.

The following patch demonstrates that it is quite easy to allow moving the toolbox to a WINDOW host.
But for some reason going back and forth between tab and window ends up being problematic.
Also, if we allow going back and forth between the two mode, it either:

  • require some more work to close and reopen the tab
  • have this "zombie" tab, when the toolbox is displayed as a window, which may cause various troubles.

At the end I'm wondering if we should instead:

  • always display in an independant window when debugging local web extension?
  • still display in a tab by default, but allow to move to a window once and disallow getting back to tab?

But for some reason going back and forth between tab and window ends up being problematic.

I think this is because the PAGE host does not create an iframe dynamically (see customIFrame), so the host switching code hangs when trying wait for the load of the iframe after setting its src attribute.

I was hoping to directly open the toolbox in a window, without creating an intermediary tab here. Ideally a window without any of the usual chrome, to minimize the risk that webextension UIs could be displayed in there.

always display in an independant window when debugging local web extension?
still display in a tab by default, but allow to move to a window once and disallow getting back to tab?

I assume that to dynamically switch the host, we need the zombie tab? If that's the case then I would rather go for your first suggestion, and always use an independent window for local extension debugging.

Attachment #9291146 - Attachment description: Bug 1780912 - [devtools] Allow the Web Extension toolboxes to be moved to a WINDOW host. → Bug 1780912 - [devtools] Open toolboxes for local WebExtension in dedicated always-on-top window.

So I provided a new patch to always open in a window host for local web extension.
I'm still not handling trying to reopen a previous toolbox is one was already opened,
but it feel less important as I'm also making this window slightly more special by being "always on top".

Now that it is a distinct window, the devtools disappear anytime you interact with the browser window,
it can easily become painful, so I think it will now be important to have such option.
Now, may be it should be something we can disable.

Attachment #9291146 - Attachment description: Bug 1780912 - [devtools] Open toolboxes for local WebExtension in dedicated always-on-top window. → Bug 1780912 - [devtools] Open toolboxes for local WebExtension in dedicated window.

This allows to keep the DevTools visible while interacting with the Firefox
window where the extension is running.

This behavior is enabled by default, but can be disable on-demand via the meatball menu.
Note that it requires to close and reopen the window/toolbox as platform APIs
disallow changing this behavior "live" on a given window.

Depends on: 1787990

Comment on attachment 9291145 [details]
Bug 1780912 - [devtools] Remove devtools.toolbox.sideEnabled

Revision D155392 was moved to bug 1787990. Setting attachment 9291145 [details] to obsolete.

Attachment #9291145 - Attachment is obsolete: true
Depends on: 1787992
See Also: → 981901
Depends on: 1788536
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/21f1e9031be0
[devtools] Open toolboxes for local WebExtension in dedicated window. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/d2360a2a3d70
[devtools] Make the local web extension toolbox be always on top. r=nchevobbe,eemeli
Backout by nerli@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c4bc92211a77
Backed out 2 changesets for causing failures in browser_aboutdebugging_addons_debug_console.js CLOSED TREE
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cd392c8b7454
[devtools] Open toolboxes for local WebExtension in dedicated window. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/45761fca51fc
[devtools] Make the local web extension toolbox be always on top. r=nchevobbe,eemeli
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 106 Branch
Flags: needinfo?(poirot.alex)
Regressions: 1807906
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: