Unable to inspect webextension popup
Categories
(DevTools :: Inspector, enhancement, P3)
Tracking
(firefox106 fixed)
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)
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/
- Debug extension, leading to "Debugging - Runtime / this-firefox" page.
- Press "Inspect", leading to "Toolbox - Extensions / myextension" page which is a viewport-less page with the devtools open.
- Use three-dot menu to turn on "Disable Popup Auto-Hide".
- 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?
Comment 1•3 years ago
|
||
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?
Reporter | ||
Comment 2•3 years ago
|
||
Thanks @jdescottes, that works for me!
Comment 3•3 years ago
|
||
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".
Assignee | ||
Comment 4•3 years ago
|
||
This has been added many years ago when introducing side hosts.
We should now consider this a builtin feature.
Updated•3 years ago
|
Assignee | ||
Comment 5•3 years ago
|
||
Assignee | ||
Comment 6•3 years ago
|
||
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?
Comment 7•3 years ago
|
||
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.
Updated•3 years ago
|
Assignee | ||
Comment 8•3 years ago
|
||
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.
Updated•2 years ago
|
Assignee | ||
Comment 9•2 years ago
|
||
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.
Comment 10•2 years ago
|
||
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.
Comment 11•2 years ago
|
||
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
Backed out 2 changesets (Bug 1780912) for causing failures in browser_aboutdebugging_addons_debug_console.js CLOSED TREE
Log: https://treeherder.mozilla.org/logviewer?job_id=389795506&repo=autoland&lineNumber=2328
Backout: https://hg.mozilla.org/integration/autoland/rev/c4bc92211a77e442ef7c738f7452b6bbbe5be9de
Comment 14•2 years ago
|
||
Comment 15•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/cd392c8b7454
https://hg.mozilla.org/mozilla-central/rev/45761fca51fc
Assignee | ||
Updated•2 years ago
|
Description
•