<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hello Blair!<br>
<br>
<br>
Le 11/04/2013 04:58, Blair McBride a écrit :<br>
</div>
<blockquote cite="mid:516618C5.2010803@mozilla.com" type="cite">THIS
IS AWESOME.
<br>
<br>
(Sorry, but that deserved all caps.)<br>
</blockquote>
<br>
Thanks!<br>
<br>
<blockquote cite="mid:516618C5.2010803@mozilla.com" type="cite">
<br>
No objections, but a couple of questions:
<br>
<br>
How does this fit into the proposal in bug 451283 for a logging
component, that would allow us to have structured logs and
potentially send some it it back via FHR?<br>
</blockquote>
<br>
This is the first time I'm reading bug 451283.<br>
<br>
First thoughts: We have NSPR, nsIConsoleService, the DOM
window.console API, dump(), toolkit/devtools/Console.jsm and one in
addon-sdk (IIANM), plus others I may not know about. Towards the end
of the list of comments I started to like the idea of the bug: a
unified logger, for JS and C++.<br>
<br>
How it fits with the Browser/Web Console? The Web Console has a
bunch of listeners for various messages and events in Gecko:
nsIConsoleService for script errors, nsIObserver for the DOM
window.console API messages and a bunch of network-related stuff.
Once the new stuff in bug 451283 lands, the Web Console can simply
tap into the new APIs: add itself as a listener, print new messages,
etc.<br>
<br>
I may have some comments for bug 451283, will see.<br>
<br>
<blockquote cite="mid:516618C5.2010803@mozilla.com" type="cite">
<br>
Are there any cases where people won't be able to use the Browser
Console? For instance, with the Chrome Debugger, since it uses the
remote debugging protocol, people on restricted OSes or have
service already running on that port may not be able to use it. It
is chrome dev stuff, so of less concern than normal content
devtools - but we do want to keep the entry barrier as low as
possible.
<br>
</blockquote>
<br>
The Browser Console also uses the remote protocol, like the Browser
Debugger. At this point we have a UX problem: the Browser Debugger
must start in a separate process. We can put the Browser Console in
that new window as well, so you have them both working at the same
time. However, when you start the Browser Console only, you do not
want to always fire up a new process (too slow, too much mem use,
etc). We haven't yet decided what we will do, but we are working
towards that.<br>
<br>
Operating system support should not be a problem - unless I'm
missing something, the Browser Console should work in all cases
where Firefox for desktop is built. Since this is not toolkit stuff
it doen't work with Thunderbird, Seamonkey, Firefox OS nor Firefox
Mobile. You can, however, use the Developer tools Connect option to
connect to a remote Firefox instance and select the main process. In
that way you get the Console and the Debugger attached to Firefox OS
and Firefox Mobile. It should work with Thunderbird and Seamonkey
instances as well - the debugger server and all of the web console
actors are in toolkit, but I didn't test them with
Thunderbird/Seamonkey.<br>
<br>
In standalone Firefox for desktop builds there should not be any
problems wrt. open ports. We make a fake internal "connection"
within Firefox when you debug things local to the instance (to
ensure good performance).<br>
<br>
<br>
Best regards,<br>
Mihai<br>
<br>
</body>
</html>