Hi, A few years ago I started working<https://code.google.com/p/gwt-in-the-air/source/browse/branches/oophm/>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<https://code.google.com/p/chromedevtools/wiki/SdkTutorial> (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
