<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 11, 2013 at 7:28 PM, Tetsuharu OHZEKI [:saneyuki_s] <span dir="ltr"><<a href="mailto:saneyuki.s.snyk@gmail.com" target="_blank">saneyuki.s.snyk@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think it's better that we add an option which starts the Browser<br>
Console in a separate process.<br>
Generally, we don't necessarily start up Browser Console in a separate<br>
process. However, we want/need to start it in another process for<br>
debugging & logging the log information in some case which an<br>
application crashes suddenly. Old tookit error console and Venkman<br>
JSDebugger is not useful from this standpoint. So the Browser Debugger<br>
which start in separate process has some advantage in this point. It<br>
can provide the last stack trace when apps crashes.<br></blockquote><div><br></div><div>You make an interesting point that I hadn't thought of. Keeping the tools running in the face of crashes may be useful in enough cases that we can ignore the increased startup latency.<br>

<br>If the extra lag in starting up the Browser Console is not deemed a serious issue, then this will certainly provide a simple and powerful way to present our host of browser tools, which right now also include the profiler, besides the console and debugger. Soon the scratchpad, style editor and page inspector will also be remotable, so they could  work from a separate process, and some of them can already target chrome code, albeit running locally.<br>

</div></div><br></div><div class="gmail_extra">The time to crack this nut is approaching, as adding more Browser Foo menu entries will soon become annoying. Bug 816325 is about figuring out a good solution to this problem.<br>

<br></div><div class="gmail_extra">Panos<br><br></div></div>