We talked about it a bit back when we started on Super Dev Mode. The main drawback is that if we take over the remote debugging protocol for a different purpose, what happens when you want to use a debugger? Also, there's no web standard as far as I know; each browser has its own protocol that they probably feel free to change.
So it seems like you'd need a complete debugger that works with many browsers. That's more than I'm willing to take on, but it seems like a good opportunity for IDE vendors who are doing that anyway. I've heard that for Chrome, the debugger UI is written in JavaScript and it seems pretty reasonable to fork it and add some GWT-specific features. (And merge changes upstream where it makes sense, so there are stable extension points.) I expect Firefox is fairly similar. This might be a good way to get started without making a big project out of it. - Brian On Wed, Dec 12, 2012 at 9:42 AM, Thomas Broyer <[email protected]> wrote: > Hi, > > A few years ago I started working on DevMode support for Adobe AIR > applications. The idea was to implement a ClientBrowserChannel that > connected to the DevMode, launched the app in debug mode (through the ADL > tool of the Air SDK) and plugged into the debugger, replacing the DevMode > plugin with breakpoints and variable manipulation (when the breakpoint is > reached, read a couple variables using the debugger API and send them to > DevMode, when a message comes back from DevMode, update those variables and > resume execution until the breakpoint is reached again; rinse and repeat). > At that time, I made a few changes to BrowserChannel to make it possible, > and the changes were merged upstream. I never finished it as I never managed > to set the breakpoint in the AIR environment. > > Given that it's becoming increasingly hard to support the DevMode plugin for > Firefox and Chrome, that those two browsers now have a remote debugging > protocol (each one their own unfortunately), and that SuperDevMode is a > different "experience" that some people don't like; I wondered if you ever > thought about such an approach as a replace for the DevMode plugin? The > downside would be that you'd have to launch the DevMode, then launch > "browser launchers" for each browser you want to debug (that acts as a > bridge between the DevMode protocol and the browser's own protocol). > I suppose that it would be rather easy (though a matter of days, not hours) > to build a prototype using the ChromeDevTools SDK (reading the docs, setting > the breakpoint should be easier than with the AIR SDK). > > An alternative could be using the browsers' debugger APIs in a browser > extension (the extension detects the ?gwt.codesvr= and sets a breakpoint in > the devmode.js, it can then talk to the DevMode using asynchronous network > APIs –e.g. WebSocket–, the breakpoint in the page guarantees that the > "application code" runs "synchronously", just like with the plugin nowadays; > there could be a global var in devmode.js that would be modified by the > "debugger" to disable loading the plugins, so the devmode.js is backwards > compatible). The downside is that the debugger API in Chrome cannot be used > at the same time as the developer tools. > > I'm just throwing the idea here, in case anyone's interested in pursuing it, > as an alternative to SuperDevMode, to continue running the code "in Java", > debugged using your preferred Java debugger. > > Note that Opera also has its own remote debugging protocol (for much longer > than the others) and could thus gain plugin-free DevMode support. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
