1300865 - Always use 'old' debugger frontend when addon debugging

Status: RESOLVED DUPLICATE of bug 1300820

(DevTools :: Debugger, defect)

Description

[Brian Grinstead [:bgrins]]

To limit scope of enabling the new debugger frontend, we could not use it when addon debugging for the time being (much like with the Browser Toolbox in Bug 1300820).

Comment 1

[Brian Grinstead [:bgrins]]

AFAIK the addon toolbox isn't using a separate profile so we can't flip a pref as in Bug 1300820.  So we might have to make some changes to switchDebugger and the build() function in definitions.js to not use the new one if target.isAddon.  I think this will be tricky because the URL is loaded before build() is called.  Not sure if there's an existing clean way to handle this case.

Comment 2

[Brian Grinstead [:bgrins]]

Ryan, does addon debugging happen in another profile?  If so, is there a place to set prefs for the profile before the toolbox initializes?

Comment 3

[Brian Grinstead [:bgrins]]

Aside: if we want to fix the breakage instead of preffing it off for now, the error at load time looks like something loader related (resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/client/debugger/new/panel.js, line 17: ReferenceError: promise is not defined)

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

The add-on debugger is also a separate process, like the Browser Toolbox.  It's the same flow as BT, just with an extra add-on ID that's passed through as a URL arg[1].

So, your change in bug 1300820 should cover add-on debugger as well.

[1]: https://dxr.mozilla.org/mozilla-central/source/devtools/client/framework/toolbox-process-window.js#44

Comment 5

[Brian Grinstead [:bgrins]]

Thanks. I tested that separately and saw still the old frontend but maybe it wasn't picked up from a ./mach build faster.  Just confirmed that it's working as expected with the patch from Bug 1300820, so duping.

Comment 6

[James Long (:jlongster)]

Oh, that's amazing. Thanks all!