Closed Bug 1170495 Opened 9 years ago Closed 9 years ago

Connecting to remote Firefox using "connect..." screen no longer shows the main process as available for debugging

Categories

(DevTools :: Debugger, defect)

35 Branch
defect
Not set
normal

Tracking

(firefox38 unaffected, firefox38.0.5 unaffected, firefox39+ fixed, firefox40+ fixed, firefox41 fixed)

RESOLVED FIXED
Firefox 41
Tracking Status
firefox38 --- unaffected
firefox38.0.5 --- unaffected
firefox39 + fixed
firefox40 + fixed
firefox41 --- fixed

People

(Reporter: Gijs, Assigned: past)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

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.
Assignee: nobody → past
Status: NEW → ASSIGNED
This must have fallen through the cracks.
Attachment #8613996 - Flags: review?(poirot.alex)
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!
Attachment #8613996 - Flags: review?(poirot.alex) → review+
(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.
Attachment #8613996 - Attachment is obsolete: true
Attachment #8614030 - Flags: review?(jwalker)
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.
Attachment #8614030 - Flags: review?(jwalker) → review+
https://hg.mozilla.org/mozilla-central/rev/788b0589c1ac
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 41
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?
Flags: needinfo?(past)
I should have toggled prefs on this new profile before calling "listen <port>" in the developer toolbar, it seems. Works now!
Flags: needinfo?(past)
Should we uplift?
Flags: needinfo?(past)
Yes, thank you!
Flags: needinfo?(past)
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
Attachment #8614030 - Flags: approval-mozilla-beta?
Attachment #8614030 - Flags: approval-mozilla-aurora?
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.
Attachment #8614030 - Flags: approval-mozilla-beta?
Attachment #8614030 - Flags: approval-mozilla-beta+
Attachment #8614030 - Flags: approval-mozilla-aurora?
Attachment #8614030 - Flags: approval-mozilla-aurora+
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.