1659618 - select elements in detached/separate developer tools window for add ons not working

Status: RESOLVED FIXED

(DevTools :: General, defect, P3)

Description

[ben]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.108 Safari/537.36

Steps to reproduce:

example 1 (React Devtool):

1. go to a webpage using react
2. open firefox developer tools in a separate window
3. go to React Developer Tools "Components" tab
4. open up settings
5. click the "Theme" setting select
6. notice options don't open
7. tab to focus "Display density" setting select
8. hit spacebar
9. notice options don't open
10. dock firefox developer tools
11. toggle f12
12. repeat steps 3-5
13. notice select option appears

example 2 (Omnibug):

1. open firefox developer tools in a separate window
2. click omnibug tab
3. click filter button
4. click "Contains" select
5. notice the select options do not appear
6. dock firefox developer tools
7. repeat steps 2-4
8. notice select options appears

Discussion in a react developer tool github issue:
https://github.com/facebook/react/issues/19618

Actual results:

Selects in detached/separate firefox developer tool window do not properly display options

Expected results:

Selects in detached/separate firefox developer tool window properly display options

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

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

The severity field is not set for this bug.
:Honza, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Julian Descottes [:jdescottes]]

Thanks for filing!

We get the following error when trying to open the Select:
TypeError: can't access property "getFullZoomForBrowser", ZoomManager is undefined

From https://searchfox.org/mozilla-central/rev/02cb78667e87ccc42fea5edc6f3f2dd2edd6ecd5/toolkit/actors/SelectParent.jsm#745

When DevTools are docked, the topBrowsingContext.topChromeWindow points to ChromeWindow chrome://browser/content/browser.xhtml
When DevTools are in a separate window, it points to ChromeWindow chrome://devtools/content/framework/toolbox-window.xhtml, which doesn't define a ZoomManager.

The previous version was using let zoom = window.ZoomManager.getZoomForBrowser(browser);, and in this case window pointed to Window chrome://browser/content/webext-panels.xhtml, which defines a ZoomManager.

Gijs: You worked on Bug 1647727, what do you think we should do here? Should we fallback on document.window.ZoomManager in case topBrowsingContext.topChromeWindow.ZoomManager is not available? Or should we make it so that ZoomManager is available on ChromeWindow chrome://devtools/content/framework/toolbox-window.xhtml (not sure what this implies)

Comment 4

[:Gijs (he/him)]

(In reply to Julian Descottes [:jdescottes] from comment #3)

The previous version was using let zoom = window.ZoomManager.getZoomForBrowser(browser);, and in this case window pointed to Window chrome://browser/content/webext-panels.xhtml, which defines a ZoomManager.

Is Window here the thing being inspected/debugged? Because using that ZoomManager actually seems pretty bad...

Gijs: You worked on Bug 1647727, what do you think we should do here? Should we fallback on document.window.ZoomManager in case topBrowsingContext.topChromeWindow.ZoomManager is not available? Or should we make it so that ZoomManager is available on ChromeWindow chrome://devtools/content/framework/toolbox-window.xhtml (not sure what this implies)

Seems like the simplest is copying https://searchfox.org/mozilla-central/rev/02cb78667e87ccc42fea5edc6f3f2dd2edd6ecd5/browser/base/content/browser.js#118-122 into a script used only from toolbox-window.xhtml ? Does that answer your question?

Comment 5

[Julian Descottes [:jdescottes]]

(In reply to :Gijs (he/him) from comment #4)

(In reply to Julian Descottes [:jdescottes] from comment #3)

The previous version was using let zoom = window.ZoomManager.getZoomForBrowser(browser);, and in this case window pointed to Window chrome://browser/content/webext-panels.xhtml, which defines a ZoomManager.

Is Window here the thing being inspected/debugged? Because using that ZoomManager actually seems pretty bad...

No, this is not the window of the debugged page. This is the window of a webextension panel in a DevTools toolbox.
We have a <select> element rendered in a DevTools webextension panel. Webextension panels are displayed in a remote frame (or browser?) pointing to chrome://browser/content/webext-panels.xhtml, which is itself embedded in the DevTools toolbox. When DevTools are in a separate window, the topmost window is the toolbox window, and it doesn't expose any ZoomManager.

Gijs: You worked on Bug 1647727, what do you think we should do here? Should we fallback on document.window.ZoomManager in case topBrowsingContext.topChromeWindow.ZoomManager is not available? Or should we make it so that ZoomManager is available on ChromeWindow chrome://devtools/content/framework/toolbox-window.xhtml (not sure what this implies)

Seems like the simplest is copying https://searchfox.org/mozilla-central/rev/02cb78667e87ccc42fea5edc6f3f2dd2edd6ecd5/browser/base/content/browser.js#118-122 into a script used only from toolbox-window.xhtml ? Does that answer your question?

Sounds like a good option, thanks!

Overall I think there is still a risk that other UI widgets might expect specific APIs to be available on topBrowsingContext.topChromeWindow.

Comment 6

[Tooru Fujisawa [:arai]]

this hit https://github.com/arai-a/ditm/issues/17
I'll try applying the suggested fix.

Comment 7

[Tooru Fujisawa [:arai]]

Attachment: Bug 1659618 - Define ZoomManager in separate devtools window. r?jdescottes!

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d93dbe2a3c9c
Define ZoomManager in separate devtools window. r=jdescottes

Comment 9

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/d93dbe2a3c9c