We should not hide error console from the UI and have just magical keyboard shortcut for it.

For example whenever we ask users to generate GC or CC logs, that requires error console access. We really don't want to make that any harder for the users, and it is very useful when users can help us debugging problems in Firefox.

Basically, we should back out Bug 602006

Maybe GC or CC logs could be generated from about:memory? Sounds to be the relevant place to go for that.

Well, GC/CC logs are just one example (also it would be tricky to handle all the CC/GC log cases in about:memory). There are other cases when one needs to be able to run chrome js. Also, atm it is very weird setup that one needs to know the shortcut key for error console. Effectively one needs to search in the internet how to open error console in Firefox. What is the reason to hide error console? Bug 602006 certainly doesn't give any reasons.

(In reply to Olli Pettay [:smaug] from comment #4) > Well, GC/CC logs are just one example (also it would be tricky to handle all > the CC/GC log cases in about:memory). If the error console managed it, about:memory can too I guess. > There are other cases when one needs to be able to run chrome js. It's possible to run chrome JS from scratchpad (you need to enable 'devtools.chrome.enabled' first). > Also, atm it is very weird setup that one needs to know the shortcut key for > error console. > Effectively one needs to search in the internet how to open error console in > Firefox. Pretty backward indeed :-p > What is the reason to hide error console? Bug 602006 certainly doesn't give > any reasons. I don't know the reason, but my guess would be the introduction of the Web Console and progressively get rid of the error console. If that's the reason, then maybe you (and anyone who cares enough) should list all the things that are missing in current devtools and prevent actually getting rid of the error console. What do you think of that plan?

Where chrome errors will be displayed after Error Console is removed?

If the error console is really being deprecated, I guess we need to change CC dumps to print to the Web Console instead of the Error Console (as was done in bug 770099 for some other messages). We use the error console to display where the file was logged. We also need some easy way to dump CC logs for the most common cases that does not require setting a config variable. We get these reports from random bug filers. Adding a button to about:memory or something could work, though we need a way to display where the file has been created. Timing information about the CC and GC are also printed to the error console.

I don't think CC/GC information, as an example, should be printed to web console. Web console should be for stuff happening in the web pages. We need some easy way to execute chrome JS and get errors, warnings and messages from chrome js. And we have that, error console, but for some odd reason it is now disabled from the UI.

I agree with Olli. There's no reason for this change except to simplify a menu that few people use anyway. Eliminating the error console will force us to do a lot of work to get to the point where things are as good as they were before. And it's not as if the web console would be improved at all if we made these updates to it, since it was designed for an entirely different purpose--debugging a single web page, rather than the browser as a whole. It might make sense to change the name from "Error Console" to something else, like "Chrome Console" or "Firefox Developer Console".

It was removed because the majority of Web Developers are not browser developers. The extra menuitem adds cognitive overhead that isn't necessary for the vast majority of Web Developers. It's an extra step for developers who are just trying to figure out why their web page isn't working as they intended. CSP information is now being sent to the Web Console because it directly relates to the webpage at hand, whereas CC/GC information is browser-wide. The Error Console is not being deprecated or phased out, it's a part of Toolkit and will remain in the product. It just doesn't need to be surfaced for all Web Developers to see. The previous solution of telling users to enable javascript.options.mem.log wasn't ideal either, since that also required many users to search the internet to find a hidden preference. Perhaps a button could be added to about:memory for users to launch the error console? This button could also enable CC/GC dumps.

(In reply to Jared Wein [:jaws] from comment #10) > Perhaps a button could be added to about:memory for users to launch the > error console? This button could also enable CC/GC dumps. If that's all the error console is used for nowadays, that sounds fine to me.

(In reply to Jared Wein [:jaws] from comment #10) > The previous solution of telling users to enable javascript.options.mem.log > wasn't ideal either, since that also required many users to search the > internet to find a hidden preference. javascript.options.mem.log has nothing to do with GC/CC logs which are created by executing some chrome js. But the point is that there are cases when we want users to be able to easily run chrome js. Also, dev tools are used only by tiny minority of our users. I highly doubt error console menu entry is too bad for the ux. Though, on linux I'd move error console out from Web developer submenu to some other place.

For addon development I could imagine error console is very useful, as is also chrome Scratchpad which is also hidden behind a pref.

It's not a matter of what percentage of our users are web developers, it's that we are spending significant effort on working to build our web developer userbase. Confusing web developers who are switching from another web browser or use multiple browsers for development isn't helping us. If we want users to run chrome JS, then we want them to use the Scratchpad in the Browser environment, which is a much better experience than the Error Console (multiline scripts, syntax highlighting, ability to save scripts, etc). (In reply to Olli Pettay [:smaug] from comment #12) > (In reply to Jared Wein [:jaws] from comment #10) > javascript.options.mem.log has nothing to do with GC/CC logs > which are created by executing some chrome js. So users would have previously needed to search the internet to find this chrome JS snippet? The only useful case that I've heard of for non-(browser/add-on) developers is the GC/CC log case as a means for support/bug filing. Why not add a button to about:memory that launches the Error Console along with that chrome JS snippet built-in? The added benefit there is that we can make sure that the chrome JS snippet remains working even after refactoring (versus the current state where docs and blogs can get out of date) potentially restricting the types of API/refactoring changes we can make. One only has to glance at Cycle Collector Heap Dump instructions [1] to see the problems we've faced with having different versions of this snippet for users. [1] https://wiki.mozilla.org/Performance:Leak_Tools#Cycle_collector_heap_dump

(In reply to Jared Wein [:jaws] from comment #14) > (In reply to Olli Pettay [:smaug] from comment #12) > > (In reply to Jared Wein [:jaws] from comment #10) > > javascript.options.mem.log has nothing to do with GC/CC logs > > which are created by executing some chrome js. > > So users would have previously needed to search the internet to find this > chrome JS snippet? The only useful case that I've heard of for > non-(browser/add-on) developers is the GC/CC log case as a means for > support/bug filing. > > Why not add a button to about:memory that launches the Error Console along > with that chrome JS snippet built-in? The added benefit there is that we can > make sure that the chrome JS snippet remains working even after refactoring > (versus the current state where docs and blogs can get out of date) > potentially restricting the types of API/refactoring changes we can make. > One only has to glance at Cycle Collector Heap Dump instructions [1] to see > the problems we've faced with having different versions of this snippet for > users. If we need to take any changes to get back to parity with FF17's error console experience, we should instead maintain the status quo for FF18 and back bug 602006.

Hiding error console makes also addon development even more difficult than it is now. We must not do that.

How about we move it to the Help menu (in a separate bug)? It really doesn't belong in the Web Dev menu anymore.

> How about we move it to the Help menu (in a separate bug)? It really doesn't belong in > the Web Dev menu anymore. How discoverable is that to people used to going Tools->WebDev ?

(In reply to Philip Chee from comment #18) > > How about we move it to the Help menu (in a separate bug)? It really doesn't belong in > > the Web Dev menu anymore. > How discoverable is that to people used to going Tools->WebDev ? More discoverable than it is now...

Ben Bucksch (:BenB) 2012-08-23 18:17:59 PDT The Error Console is critically important for me to debug stuff, both in Firefox and in extensions. That includes asking bug reporters to tell me what they see in the Error Console. Please keep it accessible, the menu item in the Tools | Developer menu doesn't hurt anybody (themenu is for developers, after all!). Or somewhere else, I don't care much where it is, as long as it's easy to find. Hidden prefs don't cut it, that's not something I can tell people to do over the phone when they run into a bug. End users (or bosses) report errors in the most loose way, and are irrational and impatient, and the Error Console is the only way for me to cut through the bushes of blabla. End users to be able to easily tell over the phone or in bug reports what the debug and error log says. Good error reporting with stacks and a useful level of debug logs are critically important to create high-quality applications.

Hmm. I do think this removal feels awkward. It's still a needed tool for those doing chrome/addon work (and occasionally end users reporting or investigating problems). I'm dropping into this late, so I'm probably missing parts of the reasoning that went into why this got nuked now. But my vague, and quite possibly incorrect, recollection from the first time this landed-and-bounced a while ago was that the prerequisites to removing this were: (1) improving the web console so that it was an acceptable replacement for web-focused tasks and (2) drafting an initial plan for what our chrome/addon development story and UX will be, so we can start moving in that direction. AFAIK #1 is well addressed with our rockin' webdev tool improvements, but I don't know the state of #2.

(In reply to Justin Dolske [:Dolske] from comment #21) > (2) drafting an initial plan for what our chrome/addon development story and > UX will be, so we can start moving in that direction. > > AFAIK #1 is well addressed with our rockin' webdev tool improvements, but I > don't know the state of #2. #2 is addressed by the Scratchpad in the Browser environment, as well as the (still-shipped) Error Console. The Error Console never was a good place to test out chrome-level JS, it just happened to be the place that worked for people.

(In reply to Jared Wein [:jaws] from comment #22) > #2 is addressed by the Scratchpad in the Browser environment, Atm it is not. Browser environment is hidden pretty effectively. Also, Scratchpad does not show JS errors happening in chrome JS.

No. By a "plan for what our chrome/addon development story and UX will be" I mean something akin to what we've done for web developers... What are the problems addon developers encounter, what are the tools that would help them, and in what form do we provide that experience? Things like an error console and scratchpad are only a tiny part of that broader plan/vision.

My thoughts: * The webdev menu is a mess right now. Removing that one command isn't changing that menu from crappy to good, just crappy to a bit less crappy. The burden is on the developer tools team to fix that (and we're working on it). * We are working on a good answer for addon developers, but we aren't there yet. * This is concretely making working with bug reporters more difficult. I won't commit to keeping this menu exactly as-is forever, but I'd rather leave it be until we have a comprehensive fix to these two problems (crappy webdev menu and piecemeal addon dev story). Moving it to Help wouldn't bother me though.

For cycle collector dumping, I don't think it really matters. Setting a pref then going to a menu isn't really any easier than just asking people to hit a magic key combo. Probably harder, in fact. So I personally don't care.

Dave, your comment is a little confusing. As of FF18, there is no error console menu item--just a keyboard shortcut. Are you in favor of putting the menu item back, or leaving it out?

Sorry - I am in favor of putting the menu back. I was arguing from the point of view of the pre-change status quo.

yeah, I'm with Dave on this. Until we have a credible replacement we should probably leave the Error Console where it is.

This patch effectively backs out the change that was landed in bug 602006 for fx18. I'd like to _not_ back this out from m-c however. I would like to perform the backout on fx19 once m-c gets uplifted to Aurora so that trunk will keep the menuitem removed and be ready for fx20 where the other devtools changes are planned.

Any reason to hide the menu item on trunk? I agree with dcamp "leave it be until we have a comprehensive fix to these two problems (crappy webdev menu and piecemeal addon dev story)" And we don't have those on trunk yet.

s/those/those issues fixed/

(In reply to Jared Wein [:jaws] from comment #30) > I'd like to _not_ back this out from m-c however. I would like to perform > the backout on fx19 once m-c gets uplifted to Aurora so that trunk will keep > the menuitem removed and be ready for fx20 where the other devtools changes > are planned. Why can't we keep the error console menu item until there's an appropriate substitute? In general, it seems like we shouldn't remove features until there's some sort of replacement that works for people. That's the whole point of this bug.

I don't think the reasons behind the decision are any less true on mozilla-central right now, let's do whatever we do on all branches.

Comment on attachment 681308 [details] [diff] [review] Backout of 602006 from Fx18 Aurora Review of attachment 681308 [details] [diff] [review]: ----------------------------------------------------------------- Why the extra "disabled" attribute? And would it be an easier patch to just swap the pref to true by default?

Comment on attachment 681308 [details] [diff] [review] Backout of 602006 from Fx18 Aurora I'm curious about your answer to questions but wouldn't hold up landing over them, so here's an r+ in case you decide not to change anything.

(In reply to Dave Camp (:dcamp) from comment #35) > Why the extra "disabled" attribute? And would it be an easier patch to just > swap the pref to true by default? Previous to my removal it had the "disabled" attribute, and the surrounding commands also have the disabled attribute. If the command has the "disabled" attribute, then the keyboard shortcut won't work. The "disabled" attribute is removed when we go to enable it. I'd like to keep it this way since the surrounding commands & menuitems follow this pattern, and it is less likely to introduce a bug if someone removes the "true || " part. Changing the pref to be true by default will break users expectations if we ever want to make the pref false by default. I'll also back out on m-c too.

This is the m-c patch. I'll land this first then request approval on the aurora patch.

Comment on attachment 681356 [details] [diff] [review] Patch Same patch as the Aurora request, no need for the extra review.

Comment on attachment 681308 [details] [diff] [review] Backout of 602006 from Fx18 Aurora [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 602006 User impact if declined: confusion about missing Error Console menuitem Testing completed (on m-c, etc.): locally Risk to taking this patch (and alternatives if risky): none expected String or UUID changes made by this patch: none

(Not sure what you want to do wrt bug 602006)

Comment on attachment 681308 [details] [diff] [review] Backout of 602006 from Fx18 Aurora [Triage Comment] Approving for FF18. If this is landed on mozilla-aurora before ~11AM PT tomorrow, this will make the merge from Aurora 18 to Beta 18. If landed 11AM-5PM PT tomorrow on mozilla-beta, it will make the first FF18 Beta. If landed after that, it will end up in the second FF18 beta.

Landed on mozilla-aurora https://hg.mozilla.org/releases/mozilla-aurora/rev/c1918be00ed2

Verified fixed on Firefox 18 RC User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 Build ID: 20130104151925

Verified fixed on Firefox 19 beta 5.