Closed Bug 951935 Opened 10 years ago Closed 10 years ago
Allow the browser console dialog to be opened in specified windows/tabs/others
I'm trying to open the Browser Console in the sidebar in my add-on. However, even though the webconsole URI loads fine there, I can't use it as a DebuggerClient to listen for messages, because most of the HUDService object is closed from the outside. This means that I can't edit its methods or assign any of its _#### properties myself. So I can't immediately ensure the console functions and is destroyed properly. The only way to do this would be to write my own HUDService, which would be pretty much a copy-paste of firefox's HUDService, except for a very few lines of code. This seems to be a big overkill. So I would suggest instead changing the current HUDService, to allow passing a window reference as an argument into the toggleBrowserConsole method as HUDService.toggleBrowserConsole(aWindow). The method would use aWindow in its openWindow method instead of opening a new one (if null or nothing is passed, it will still open a new window, as is current behavior). AFAICT, this would be a very simple change, which works great for opening, working with, and closing browser consoles in windows other than the dialog opened by HUDService itself, making sure they are handled properly in all these cases by the original HUDService. Although admittedly, I'm not 100% sure if my suggestion can be implemented exactly like this, as I've read too much code today and I'm already at the stage of seeing many happily colored words when I blink... So I could be wrong, and in that case (or if I missed an incredibly obvious way to do what I want) I would greatly welcome any alternatives for my situation, if it is at all possible. :)
In the past months we've made changes to how things work. You can load the webconsole.xul in a sidebar, and create WebConsole or BrowserConsole instances for that iframe. You just need to require() hudservice.js, and call openWebConsole()/openBrowserConsole(). Both methods take the arguments you need: a target to listen messages for, the window object of the iframe which holds the UI (webconsole.xul), and the chrome window which holds that iframe. Marking the bug as WFM. Please reopen if you find otherwise. Thank you.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Yes, true, but that still requires me to get the target object. Seeing as I don't want "a target" but I want the console to debug the global process (literally make Ctrl+Shift+J open in the sidebar), and please correct me if I'm wrong, I would still need to basically copy the whole toggleBrowserConsole() method, except for a very small change in its openWindow() sub-method to lead to the sidebar, instead of opening its own. I thought it would be much easier to add a switch in there, where it would use whatever window object was provided as toggleBrowserConsole(aWindow) instead of opening a new one (only if provided of course). Obviously that's what I'll do if you still think this is not worth changing the HUDService code for. I just thought it would be a very simple change, which would benefit everyone working with the browser console in other places. It would definitely ensure compatibility to be maintained, relative to where the console opens, if the code is changed somewhere else; i.e. I don't have to keep updating my code to match yours, just so it opens wherever I want it.
You need to log in before you can comment on or make changes to this bug.