Closed Bug 1300865 Opened 3 years ago Closed 3 years ago
Always use 'old' debugger frontend when addon debugging
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).
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.
Ryan, does addon debugging happen in another profile? If so, is there a place to set prefs for the profile before the toolbox initializes?
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)
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. So, your change in bug 1300820 should cover add-on debugger as well. : https://dxr.mozilla.org/mozilla-central/source/devtools/client/framework/toolbox-process-window.js#44
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.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1300820
Oh, that's amazing. Thanks all!
You need to log in before you can comment on or make changes to this bug.