Panos says this regressed sometime in the 39 timeframe. It's blocking some of my win10 investigations. I'll try to find a regression range.

This must have fallen through the cracks.

I am but a stranger in these parts, but shouldn't setting that flag be conditional on the relevant pref (enable chrome/add-on debugging) being enabled?

Comment on attachment 8613996 [details] [diff] [review] Let the debugger server started by GCLI debug chrome code Review of attachment 8613996 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for the report'n patch!

(In reply to :Gijs Kruitbosch from comment #2) > I am but a stranger in these parts, but shouldn't setting that flag be > conditional on the relevant pref (enable chrome/add-on debugging) being > enabled? That's a good point. I'll update the patch.

Trying to use the hiddenByChromePref() GCLI helper, pointed at another bug: we recently made devtools.chrome.enabled a sticky pref. That means it is no longer meaningful to test it with prefHasUserValue(), because it will always have one in order for it to be persisted. We now have to check the actual value it contains. Also, nsIPrefBranch2 has been merged into nsIPrefBranch a long time ago.

I should add that toggling the "enable add-on and chrome debugging" checkbox in the options panel doesn't have any effect on hiddenByChromePref() without this patch. You have to explicitly go to about:config and reset the pref (not toggle it) for that function to return a different value.

I've tried using the Web IDE to connect to today's Fennec nightly (build ID 20150605030205) and I still cannot select the main process for debugging. The regression range (http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0189941a3fd5&tochange=43fb1f92e8d4) points me to bug 1059308 as well, so I assume that it's the same underlying issue as on desktop.

Please file a separate bug and CC me.

I'm still seeing this on current fx-team builds with two nightlies with all the relevant prefs set. Are we sure this is fixed?

I should have toggled prefs on this new profile before calling "listen <port>" in the developer toolbar, it seems. Works now!

Should we uplift?

Yes, thank you!

Comment on attachment 8614030 [details] [diff] [review] Let the debugger server started by GCLI debug chrome code v2 Approval Request Comment [Feature/regressing bug #]: bug 1059308 [User impact if declined]: debugging Firefox by starting a debugger server from the developer toolbar is not possible. The set of people affected by this is mostly Firefox developers and possibly some add-on developers [Describe test coverage new/current, TreeHerder]: manual tests in nightly [Risks and why]: minor risk as the fix is localized in GCLI, a devtools feature not widely used [String/UUID change made/needed]: none

Comment on attachment 8614030 [details] [diff] [review] Let the debugger server started by GCLI debug chrome code v2 Approved for uplift to aurora and beta. Good to avoid ever shipping this regression.