User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100918 Firefox/4.0b6pre Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100918 Firefox/4.0b6pre The error console is ESSENTIAL for "in live" debugging as opposed to debugging that takes place in a development or test phase of a project. At the moment if I receive a bug report against one of our live intranet apps the first thing I ask the reporter to do is check the Firefox error console. This will contain any warnings and errors that have happened on any page since the browser was started. This is important because often the user won't know or remember exactly what they did, even which page they were on. Often I don't get to speak to them about the issue until a couple of hours after the problem happened. But 9 times out of 10 the messages in the error console provides a strong clue as to what's wrong. The web console does not address these scenario well because (1) it only captures errors while its open and (2) it and the errors it contains disappear when the page is closed. So what I'm saying in a roundabout way is that there is huge value in having the old error console enabled by default. The web console and error console are complimentary tools - one does not completely replace the other. Reproducible: Always

firefox -jsconsole will bring up the console in an existing firefox instance. Isn't that OK on the rare occasions you'll need it?

Might be possible but I think I would struggle with some of the users (who are not IT literate and already hostile because of the problem they've hit) if I had to talk them through launching a DOS prompt, possibly setting their path, running a command (which they will mis-key several times) then going to the console to get the error messages. I've got some of the users quite well trained at going to the console whenever a problem happens. It's easy to do and it seems a shame to make it harder.

email them this and ask them to paste it into the run box. Should work in most cases... "C:\Program Files\Mozilla Firefox\firefox.exe" -jsconsole

I suppose. I think you're underestimating the level of grumpiness and negativity of some of our people here ! What's actually to be gained by disabling the console ?

Most folks don't understand what's in it e.g. your own non IT literate userbase for instance.

That's true but they've lived with it so far and they won't understand the new web console either. If you're worried about menu clutter, what about a button to launch the old error console from the web console. Then it's only one extra navigation for an expert and well enough buried for a novice to never come across it.

What about Bug 598032

Personally, I agree with this report to a certain degree. Either it's useful enough to have, or get rid of it completely. It's not fun, entertaining or shocking enough to be an "easter egg" and when not in the primary ui it isn't useful at all. Who's gonna maintain a window that has no primary ui? Just adds bloat and startup waste of time... For the record, as it stands now I think it is useful since it will recall all messages, not just from when it was opened. This is a huge advantage, because I'm not always running with the console open. I say "as it stands now" because this behavior should really just be incorporated into the Web Console and then this can really be axed. Separate bug though, perhaps blocking this one...

(In reply to comment #7) > What about Bug 598032 That seems a decent enough solution, one I could talk our users through. I voted for that bug

for testing web page errors, the Web Console is provided by default. The error console is for browser chrome errors. There's a pref (devtools.errorconsole.enabled) to turn it on if it's required.

I did try to explain why the web console is not satisfactory for some real-world debugging scenarios but....

(In reply to comment #10) > for testing web page errors, the Web Console is provided by default. The error > console is for browser chrome errors. There's a pref > (devtools.errorconsole.enabled) to turn it on if it's required. You haven't provided answers for any of the issues raised in this bug, not by the reporter or by myself. The title may be a wontfix but _some_ solution should be provided for these issues (which to me seems mostly the fact that it doesn't give you the errors encountered before the Console was opened). At that point this can either be moved to a new bug, or this bug can be morphed. As it is, I don't see why you WONTFIXED this bug, so I'm reopening.

Yes, there are options and perhaps the title should be generalised - Enable old error console by default - Provide an easy navigation to the old error console, e.g. from about:support - Enhance the web console to provide the functionality

(In reply to comment #12) > The title may be a wontfix but _some_ solution > should be provided for these issues (which to me seems mostly the fact that it > doesn't give you the errors encountered before the Console was opened). This is indeed an issue, we are working on a partial fix in bug 587734 (which fixes this for the console's API - log, info, warn, error) and long term we will need to get all of our observers caching messages as well. Just for the record, I never wanted to hide the Error Console, just rename it to something like "Browser Console". This started some bikeshedding and then folks were worried about confusion of 2 consoles. The fact remains some people will still need 2 consoles for some time after FX 4 ships.

Hopefully better title

changing the title doesn't change the state of anything. We've preffed off the error console by default and it's a simple, one-time change for a user to re-enable it. When the web-console is functioning as intended (as David mentions, bug 587734) much of the functionality that is required to debug a website will be in place in the Web Console. Next version of Firefox will likely not have the Error Console at all.

I'm gonna note the dependency for now, with that bug fixed aiui most of the functionality requested here will be available.

(In reply to comment #17) > I'm gonna note the dependency for now, with that bug fixed aiui most of the > functionality requested here will be available. Seems like an enhance web console is the future. If bug 587734 gives us messages logged before the console was opened, that's a step forward for sure. But I also mentioned the requirements to (1) view at messages generated by a tab or window that has since been closed and (2) view at messages without knowing which window created them ? For me, those are important features of the error console.

(In reply to comment #16) > Next version of Firefox will likely not have the Error Console at all. Uh...? The Error Console is toolkit, and as irrelevant as it is to Firefox, that's not the case with toolkit. So how is that going to work? By "not have", do you mean that Firefox isn't going to include its devtools.errorconsole.enabled pref listener (as it is now), or are you actually saying it's going to be excised from toolkit?

There will certainly be something that serves the purpose of the Error Console in the toolkit.

(In reply to comment #19)> (In reply to comment #16)> > Next version of Firefox will likely not have the Error Console at all.> > Uh...? The Error Console is toolkit, and as irrelevant as it is to Firefox,> that's not the case with toolkit. So how is that going to work? By "not> have", do you mean that Firefox isn't going to include its> devtools.errorconsole.enabled pref listener (as it is now), or are you actually> saying it's going to be excised from toolkit?There is not a solid "roadmap" or decision for this yet. You are correct in saying that as the Error Console is in toolkit, it will still be "there", but it may be that we use the guts of the new Web Console to make a new improved "Browser Console" that supercedes the JS Error Console as it is today.

> There will certainly be something that serves the purpose of the Error Console > in the toolkit. There are toolkit applications that aren't web browsers (Thunderbird, eMusic Download Manager, loads of xulrunner apps). The Toolkit Error Console should be retained because there are still consumers that can't use the Web Console (enhanced or not).

Yes, we understand that there are other, non-browser toolkit apps, and that's actually what I was trying to say when I said "serves the purpose of the Error Console". As David says, the roadmap is not there yet... the Web Console *could* move out of toolkit into browser, or the Web Console code could be extended so that its user interface can be pulled into a separate window and operate in chrome space. (Thus upgrading the Error Console to have search, etc.)

FYI People who use my Error Console replacement http://console2.mozdev.org/ already have search and filter capabilities using a "google lite" syntax.

The Error Console is available by default (and I believe this was the case in Firefox 4 when we shipped the web console). As of today, the other problem described in the initial report is now fixed as well: messages logged to the web console before the console was opened are retained.