I have no idea, but I doubt it. Although, yes, it should really be standardized though, like the JVM debug protocol.
The Google Web Toolkit team was looking at this; instead of their historical approach of using a JVM to run/debug user code (because that was actually a really great idea in IE6), using the native JS debuggers in FF/Chrome/etc.
...except that there is all sorts of wonkiness, like only 1 debugger is supported at a time, so you can't use, say, Eclipse (whether for GWT or pure JS debugging) + FF dev tools for inspecting CSS/etc. at the same time. And you can only connect to 1 tab...something, something. I was not directly involved, but it didn't sound pleasant.
Anyway, I totally agree that native dev tools should be decoupled/play friendly with other tools.
AFAICT, so far the FF/Chrome engineers are going down the path of basically building IDEs from scratch, in the browser itself.
Which was great for Firebug, and inspecting elements, but for a debugger, I really want to stay in my IDE.
The Google Web Toolkit team was looking at this; instead of their historical approach of using a JVM to run/debug user code (because that was actually a really great idea in IE6), using the native JS debuggers in FF/Chrome/etc.
...except that there is all sorts of wonkiness, like only 1 debugger is supported at a time, so you can't use, say, Eclipse (whether for GWT or pure JS debugging) + FF dev tools for inspecting CSS/etc. at the same time. And you can only connect to 1 tab...something, something. I was not directly involved, but it didn't sound pleasant.
Anyway, I totally agree that native dev tools should be decoupled/play friendly with other tools.
AFAICT, so far the FF/Chrome engineers are going down the path of basically building IDEs from scratch, in the browser itself.
Which was great for Firebug, and inspecting elements, but for a debugger, I really want to stay in my IDE.