[Developer Tools] "Enable the browser chrome and add-on debugging toolboxes" and "Enable remote debugging" should be merged into one option
Categories
(DevTools :: General, enhancement, P5)
Tracking
(Not tracked)
People
(Reporter: hazard-waltzer02, Unassigned)
References
Details
+++ This bug was initially created as a clone of Bug #1627942 +++
User Agent: Mozilla/5.0 (X11; CrOS x86_64 12739.111.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.162 Safari/537.36
Steps to reproduce:
Go to DevTools settings
Actual results:
Notice that there are two checkboxes you have to check.
Expected results:
The two boxes should be merged into one.
Reporter | ||
Comment 1•5 years ago
|
||
By the way, I accidentally marked the bug as security and didn't know how to take it off. So I had to clone it.
Comment 2•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 3•5 years ago
|
||
Julian, since this would make onboarding addon devs easier, are there reasons we should treat those checkboxes separate on Desktop?
Reporter | ||
Comment 4•5 years ago
|
||
(In reply to :Harald Kirschner :digitarald from comment #3)
Julian, since this would make onboarding addon devs easier, are there reasons we should treat those checkboxes separate on Desktop?
It would not. With the new HTML about:debugging in Firefox 69, add-on debugging is always-on, no matter what the checkboxes say in DevTools.
Comment 5•5 years ago
|
||
(In reply to Nicohumor from comment #4)
(In reply to :Harald Kirschner :digitarald from comment #3)
Julian, since this would make onboarding addon devs easier, are there reasons we should treat those checkboxes separate on Desktop?
It would not. With the new HTML about:debugging in Firefox 69, add-on debugging is always-on, no matter what the checkboxes say in DevTools.
Exactly, addon debugging no longer relies on this pref since https://bugzilla.mozilla.org/show_bug.cgi?id=1525533
Which means the label of the setting should at least be updated.
I think we had a bug to review the usefulness of the preference but can't find it anymore. Found an old one though: https://bugzilla.mozilla.org/show_bug.cgi?id=1210790
The preference driven by this checkbox is: devtools.chrome.enabled
. Let's take the opportunity to review the preference usage quickly.
- detect if the BrowserToolbox is enabled in the storage actor (at least that's the intent, but preferences can't really tell you this)
- showing chrome events in the inspector
- allow to debug the payment dialog
- avoid rendering the WebConsole input (JSTerm) in the BrowserConsole (but this is slightly buggy in recent builds, as the JSTerm or the edit panel are visibly replaced by blank areas)
- immediately allow pasting in the console
- enable the Browser Toolbox (also here)
So it's a mixed bag, but the preference is still widely used, sometimes incorrectly (storage actor should check if we are debugging the main process? pasting threshold in console should rather be linked to local builds?)
Let's rename the option's label for now.
Comment 6•5 years ago
|
||
Ah I missed that the question was about merging them or not.
If you want to use remote debugging, you need to enable chrome debugging.
Using chrome debugging without remote debugging is virtually useless because you can't start the browser toolbox...
I think it makes sense to merge them. The option label would be something like "Enable remote and browser chrome debugging".
When it comes to the pref to use, it would be nice to rename it (devtools.chrome-remote.debugging
, devtools.chrome-and-remote.debugging
?). I don't know if there is an easy way to migrate preferences (eg initialize this new preference by reading the value of the previous prefs?)
Reporter | ||
Comment 7•5 years ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #6)
Ah I missed that the question was about merging them or not.
If you want to use remote debugging, you need to enable chrome debugging.
Using chrome debugging without remote debugging is virtually useless because you can't start the browser toolbox...I think it makes sense to merge them. The option label would be something like "Enable remote and browser chrome debugging".
When it comes to the pref to use, it would be nice to rename it (devtools.chrome-remote.debugging
,devtools.chrome-and-remote.debugging
?). I don't know if there is an easy way to migrate preferences (eg initialize this new preference by reading the value of the previous prefs?)
I think that devtools.debugger.remote-enabled
should be removed, and just devtools.chrome.enabled
should remain. If we rename the preference then after an update the Browser Toolbox would not be enabled anymore.
Also, I'd recommend the checkbox name to be "Enable the Browser Toolbox and remote debugging".
Reporter | ||
Comment 9•5 years ago
|
||
When will this land in Nightly?
Comment 10•5 years ago
|
||
(In reply to Nicohumor from comment #8)
I think that devtools.debugger.remote-enabled should be removed, and
just devtools.chrome.enabled should remain. If we rename the preference
then after an update the Browser Toolbox would not be enabled anymore.
We can add logic to migrate the old prefs to a new one, I don't intend to break the profiles that already enabled the prefs...
It's important to keep preferences names in sync with what they do.
(In reply to Nicohumor from comment #9)
When will this land in Nightly?
The bug is not assigned currently. First someone needs to take the bug, submit a patch, get it reviewed and then it will land.
Reporter | ||
Comment 11•5 years ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #10)
(In reply to Nicohumor from comment #8)
I think that devtools.debugger.remote-enabled should be removed, and
just devtools.chrome.enabled should remain. If we rename the preference
then after an update the Browser Toolbox would not be enabled anymore.We can add logic to migrate the old prefs to a new one, I don't intend to break the profiles that already enabled the prefs...
It's important to keep preferences names in sync with what they do.(In reply to Nicohumor from comment #9)
When will this land in Nightly?
The bug is not assigned currently. First someone needs to take the bug, submit a patch, get it reviewed and then it will land.
Adding logic wouldn't be a good idea because simply removing one preference (devtools.debugger.remote-enabled
) is possible and is the easiest way to fix this bug.
Updated•5 years ago
|
Updated•2 years ago
|
Description
•