Re: JS debugger on conceptual level

John J. Barton wrote:
> Gijs Kruitbosch wrote:
>> Yeah, remote (out-of-process) debugging in Mozilla is not trivial. I 
>> am not sure how you'd go about doing it - both Venkman and Firebug are 
>> in-process, which makes the process easier in a way. You could 
>> probably have part of your app install an add-on that deals with the 
>> Firefox interfaces for you, and control that add-on through whatever 
>> manner you wish (pipes/COM/screenscraping/local webserver/what-have-you).
> 
> I would say this even much stronger: out-of-process debugging is beyond 
>  technical feasibility as a practical matter. It would require 
> interpreting and manipulating the bit image of the remote process. C 
> debuggers do this for C code, it is very difficult. While it has some 
> advantages, doing it for the complete mozilla run time is not likely.
> 
> I call the thing Gijs describes 'proxied debugging', where the debugger 
> UI is in one process talking to server in the debuggee. I guess that 
> what Dan is talking about when he says "remote".
> 
> I believe some folks are confusing proxied debugging and out-of-process 
> debugging, which have different cost/benefits. In particular the so 
> called "uncertainty" problem of a runtime with an embedded debugger 
> cannot be completely removed in proxied debugging.
> 
> jjb

Well fine. I apologize if I was not very strict in terms of terminology. I can't 
think of any external interfaces that we have for debugging. In fact, just in 
general the only interfaces I can think of that manipulate 
Gecko/"Mozilla"/Firefox from the outside (without sneaking in on the inside 
first) are gtkmozembed and the Mozilla ActiveX control. Neither allows you the 
kind of control you want for debugging, I'm pretty sure.

~ Gijs