1757741 - Browser Toolbox only shows Console Debugger and Memory panels

Status: RESOLVED WORKSFORME

(DevTools :: General, defect)

Description

[Julian Descottes [:jdescottes]]

:mardak and :mviar both reported a similar issue with the Browser Toolbox.

On a local build, the Browser Toolbox only shows 3 panels: console, debugger and memory.
This happens on a recent central with no local change, and happens with clean profiles.

This toolset usually indicates that we are debugging a Content Process, ie using the Browser Content Toolbox, but we checked that this was not the case here:

• we tried to start the toolbox with ./mach run --jsdebugger
• we added logs in RootActor:getProcess and checked the queried id was 0
• users can enable the Multiprocess Browser Toolbox option, and the window will take the title "Multiprocess Browser Toolbox"

So everything seems to indicate that we open a Multiprocess Browser Toolbox, but we end up debugging a Content Process Target.

Considering the implementation of the process descriptor, I don't see many reasons why this could happen. If id is 0 then the process descriptor should try to create a parent process target, meaning it should use https://searchfox.org/mozilla-central/rev/292d17c13daa61016fd082e2337297091d53a015/devtools/server/actors/descriptors/process.js#74

The only thing I could see which would make it behave incorrectly is if we find XPCSHELL_TEST_PROFILE_DIR in the environment variables and think we are debugging XPCSHELL tests.

Comment 1

[Julian Descottes [:jdescottes]]

:mardak, :mviar

Could you check if XPCSHELL_TEST_PROFILE_DIR is for some reason set in your environment?

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'DevTools::Console' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Ed Lee :Mardak]

I was relaying information from mviar yesterday, but things do work for me. We do use remote settings devtools, which does require setting XPCSHELL_TEST_PROFILE_DIR when not using nightly: https://github.com/mozilla-extensions/remote-settings-devtools/issues/44#issuecomment-593640714

I can confirm "Multiprocess Browser Toolbox" only has Console, Debugger, Memory when run with XPCSHELL_TEST_PROFILE_DIR=foo ./mach run --temp-profile where Services is undefined from its console (as well as from Tools -> Browser Console).

Comment 4

[Julian Descottes [:jdescottes]]

Thanks for the info!

So a few things come to mind when reading the GH issue. First, we should only need this when testing RELEASE or BETA, for local builds there is no reason to set this environment variable.

More importantly, I recently changed this code so that it depends on MOZ_DISABLE_NONLOCAL_CONNECTIONS instead of XPCSHELL_TEST_PROFILE_DIR: see the latest code at https://searchfox.org/mozilla-central/source/services/settings/Utils.jsm#52 , meaning the current workaround with XPCSHELL_TEST_PROFILE_DIR will no longer work for Firefox 99 :/

The reason we switched to MOZ_DISABLE_NONLOCAL_CONNECTIONS is that all test harness which can't do connections need to replace this URL with a dummy one. And of course you cannot set this for testing because it would prevent your Firefox from doing any non-local connection.

So if it is still important to be able to switch environments in Beta/Release, we need another environment variable to support this, which would be explicitly about Remote Settings DevTools.

Comment 5

[Meg Viar [:mviar]]

Thanks, jescottes. As Mardak mentioned, yes XPCSHELL_TEST_PROFILE_DIR was set. We've discussed the change that will affect the remote settings devtools workaround with the Onboarding, Messaging, and Communications team.

Comment 6

[Ed Lee :Mardak]

With bug 1757744 fixed, "Browser Toolbox" now shows up as "XPCShell Toolbox" when setting XPCSHELL_TEST_PROFILE_DIR. To get Remote Settings Devtools to switch to "Stage" environment on beta/release, here's a Browser Console workaround:

XPCOMUtils.defineLazyPreferenceGetter(
  ChromeUtils.import("resource://services-settings/Utils.jsm").Utils,
  "SERVER_URL",
  "services.settings.server"
)

https://github.com/mozilla-extensions/remote-settings-devtools/issues/44#issuecomment-1062060893

That workaround seems to be sufficient for testing with stage remote settings, but if not, we can file a new Remote Settings Client bug.

Comment 7

[Julian Descottes [:jdescottes]]

(In reply to Ed Lee :Mardak from comment #6)

That workaround seems to be sufficient for testing with stage remote settings, but if not, we can file a new Remote Settings Client bug.

A bug was already filed at Bug 1758645, so we will have a workaround similar to the XPCSHELL_TEST_PROFILE_DIR one soon.