602006 - Remove Error Console Menu Items

Status: VERIFIED FIXED

(Firefox :: General, defect, P1)

Description

[:Gavin Sharp [email: [e-mail]]]

The Error Console was re-enabled in bug 601201, because the web console doesn't currently support showing errors that were reported before it was opened. Once that's fixed (bug 601260), we should re-hide the error console.

Comment 1

[Dietrich Ayala (:dietrich)]

Does this actually need to block beta 8? Or can we have it block betaN, and take it opportunistically if ready?

Comment 2

[Kevin Dangoor]

Though I think this will get into beta8, based on how things are going, I'm fine with calling it a betaN blocker.

Comment 3

[Nochum Sossonko [:Natch]]

IMO, this can't happen until bug 568629 comment 95 is addressed. With the error console there was always the option of debugging a page. With the new console object websites can override that and take this option away. This is important, and should be addressed (perhaps by defining an internal, non-accessible, constant frozen object that the console service uses internally) before disabling the error console.

Comment 4

[Kevin Dangoor]

bug 568629 comment 95 is saying that messages sent to window.console will not appear in the Web Console if the page defines its own console object. All of the other logging (network traffic, JS and CSS errors) will continue to appear in the Web Console (those don't go through window.console).

Comment 5

[Nochum Sossonko [:Natch]]

(In reply to comment #4)
> bug 568629 comment 95 is saying that messages sent to window.console will not
> appear in the Web Console if the page defines its own console object. All of
> the other logging (network traffic, JS and CSS errors) will continue to appear
> in the Web Console (those don't go through window.console).

The question I asked was whether errors and warnings will show in the console. The answer was no. If this is indeed the case that errors and warnings do show, then scratch comment 3. :)

Comment 6

[Kevin Dangoor]

Aha, I think there was some confusion. When you said errors/warnings/logs, my guess is that ddahl interpreted that to mean messages passed to console.error, console.warn, console.log, all of which would not be displayed in the Web Console. Errors originated from other parts of Firefox should still appear in the console (and if you try it today on a site like cnn.com which defines a console object, you'll see that the other messages do appear...)

Comment 7

[Kevin Dangoor]

Re-requesting blocking: this is not a beta8 blocker, but should be a betaN blocker. This is dependent on all of the various lazy console bits landing and those are not beta8 blockers.

Comment 8

[Kevin Dangoor]

mass change: filter mail on BLOCKERSETTING

Comment 9

[Rob Campbell [:rc] (:robcee)]

Attachment: patch

new patch to disable the error console.

Had to disable the pref in build/automation.py.in (bug 595527) to get this to pass. We might want to fudge around that with a new mochitest pref to turn it back on. Followup bug?

Comment 10

[Dave Townsend [:mossop]]

We can't both have a test that verifies the console is disabled in the automated test run and have the console enabled in the automated test run. I think the latter is the preferable course in terms of developer sanity. Drop the test and let's make sure we have a litmus test or something checking it in a new profile.

Comment 11

[Dave Townsend [:mossop]]

Comment on attachment 493993 [details] [diff] [review]
patch

Technically I can't review this but I doubt anyone will mind me saying r+ to the browser/base/content/browser.js change. Drop the rest I think.

Comment 12

[Rob Campbell [:rc] (:robcee)]

I thought that might be the outcome and at least verified that my test passes with the change to automation.py. I'll create a litmus test for this before it's ready to check in.

thanks!

Comment 13

[Rob Campbell [:rc] (:robcee)]

We're still looking to do this for Firefox 4 final. Just waiting on some clarification from limi on how he'd like us to proceed.

Comment 14

[Alex Limi (:limi) — Firefox UX Team]

I'll admit to having used neither extensively, so I can't comment on its readiness and applicability for the average developer. You guys will have to make the call there.

If you guys think the new console is much better, and the only downside is that it doesn't show errors in the past (nor chrome errors), I'd say it would be a fair way to have your cake and eat it too.

Keeping the existing keyboard shortcut for Error Console (so the people that are used to it being available can reach it) and having only the Web Console in the menu seems like a good compromise to me.

Comment 15

[Kevin Dangoor]

(In reply to comment #14)
> If you guys think the new console is much better, and the only downside is that
> it doesn't show errors in the past (nor chrome errors), I'd say it would be a
> fair way to have your cake and eat it too.

Yes, exactly. The only bit that hasn't made it for the Web Console is the ability to display messages that came up before the console was opened (a limitation that Firebug also has, I'll note). We want the Web Console, but I think leaving the two menu items will likely be confusing.

I think it would be fine to remove the Error Console menu item but leave the keyboard shortcut active, but I'll suggest that we should document how to access the error console on the Using the Web Console page[1] and possibly the help page[2] as well.

[1]: https://developer.mozilla.org/en/Using_the_Web_Console
[2]: https://developer.mozilla.org/AppLinks/WebConsoleHelp?locale=en-US

Comment 16

[Boris Zbarsky [:bzbarsky]]

The attached patch makes the error console totally inaccessible as far as I can see.  Shouldn't the keybinding be enabled if the menuitem is not or something?

Comment 17

[Rob Campbell [:rc] (:robcee)]

Attachment: hide menu items

Hiding menu options, while leaving the command enabled.

Comment 18

[Rob Campbell [:rc] (:robcee)]

(In reply to comment #16)
> The attached patch makes the error console totally inaccessible as far as I can
> see.  Shouldn't the keybinding be enabled if the menuitem is not or something?

yes, that's why in the post on d-a-f I said "patch pending". :)

try the new one I just posted.

Comment 19

[Dão Gottwald [:dao]]

Is this the right patch? I don't understand what it's trying to do.

Comment 20

[Rob Campbell [:rc] (:robcee)]

Comment on attachment 510647 [details] [diff] [review]
hide menu items

I generated this with another patch applied underneath it. Please disregard until I get a proper patch generated. Thanks for catching, dao.

Comment 21

[Rob Campbell [:rc] (:robcee)]

Attachment: error console key

try this!

Comment 22

[Kevin Dangoor]

In order to avoid churn and get more feedback from users before making this change, we're going to postpone this until after Firefox 4. (This is the route preferred by the Firefox module owner.)

http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/d8e7c1976d4d8448#

As I mentioned in that thread, I haven't seen any Input that reflects real-world confusion between the Error Console and the Web Console, so it's possible that my fears there are unfounded.

Comment 23

[Dão Gottwald [:dao]]

Comment on attachment 510651 [details] [diff] [review]
error console key

This patch kills support for the hidden pref.

Comment 24

[Rob Campbell [:rc] (:robcee)]

UX said it wasn't necessary.

Comment 25

[Dão Gottwald [:dao]]

Who's UX and what's the reasoning? But your patch is bogus anyway, as it removes neither the hidden pref (it just prevents it from working) nor the menu items (it just hides them all the time).

Comment 26

[Jared Wein [:jaws] (please needinfo? me)]

This bug was set to be fixed once bug 601260 (which was duped to bug 611032) was landed.

Can this be fixed now or is there something else that blocks this that I don't see?

Comment 27

[Kevin Dangoor]

Looking back at the d-a-f thread (now a year old), it would seem that you're right. The comments there (about console messages from before the console was opened and the ability to put the console in a separate window) have both been dealt with.

Searching input just now, it appears that the input we're getting is about the web console, but it's actually hard to tell in some cases if they're referring to the web console or the error console. From that perspective, it would be a good thing to hide the error console, which has less to offer web developers than the web console.

Comment 28

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug

This patch just removes the enabled-by-default nature of the error console. Enabling the devtools.errorconsole.enabled about:config pref will show the menuitems, but the key binding will continue to work even though the visible menu items are hidden.

Comment 29

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 632136 [details] [diff] [review]
Patch for bug

Review of attachment 632136 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/browser.js
@@ +1501,3 @@
>    if (consoleEnabled) {
>      document.getElementById("javascriptConsole").hidden = false;
>      document.getElementById("key_errorConsole").removeAttribute("disabled");

Whoops, I forgot to remove this line since the disabled attribute isn't present on this anymore. For purposes of code review, please assume that this line has been removed.

Comment 30

[:Gavin Sharp [email: [e-mail]]]

I'm not opposed to this, but it should be explicitly acknowledged that the Web Console still does not display certain types of warnings, e.g. bug 760847.

Comment 31

[Jared Wein [:jaws] (please needinfo? me)]

I didn't realize the issues with CSP not appearing in the web console. From reading through those bugs it looks like there isn't any progress currently being made on fixing that.

Sid and Brandon, would you be OK with us disabling the visible access to the Error Console? Users could still access it through keyboard shortcuts or by enabling an about:config pref, but default menu navigation to the Error Console will be removed if I land this patch.

Comment 32

[:Gavin Sharp [email: [e-mail]]]

CSP likely isn't the only such example, it's just the only one I could remember. Since the Web Console uses a whitelist of "types" to display, and only shows items that can be associated with a specific window, it's necessarily going to only show a subset of the warnings that are displayed by the Error Console.

Comment 33

[Boris Zbarsky [:bzbarsky]]

Case in point: it doesn't show the GC log information...

Comment 34

[Jared Wein [:jaws] (please needinfo? me)]

So should I hold off on landing this patch? It's my understanding (and perhaps incorrect) that besides CSP, the only difference between the web console and the error console are items that are of interest to browser developers.

The error console will still be accessible through the keyboard shortcut, and if the pref is enabled then the menuitem will appear.

It may seem like a trivial thing to remove, but it will be one less item to visually scan when opening the now quite-long Web Developer menu.

Comment 35

[Kevin Dangoor]

I don't like the idea of web developers having to find a hidden tool to show them the CSP warnings. It's bad enough that they have to go to another tool to find them.

I am very keen to remove the menu item both because of visual scanning and potential for confusion ("do I want the Web Console or the Error Console?"). But I'm inclined to wait until we're pretty sure that the interesting things for web developers are appearing in the Web Console.

Comment 36

[Ben Bucksch (:BenB)]

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.

Comment 37

[Jared Wein [:jaws] (please needinfo? me)]

Marking as dev-doc-needed and addon-compat since this changes the developer tools menu and may affect addon developers.

The Error Console is still accessible through the preexisting keyboard shortcut (ctrl+shift+J on Windows, cmd+shift+J on Mac). To re-enable the menuitem, go to about:config and set the devtools.errorconsole.enabled=true.

Landing this now since the CSP warnings are now being sent to the Web Console (bug 770099).

https://hg.mozilla.org/integration/mozilla-inbound/rev/42a7cb309ca1

Comment 38

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/42a7cb309ca1

Comment 39

[Andrew McCreight [:mccr8]]

One bit of documentation that needs to be updated is
https://wiki.mozilla.org/Performance:Leak_Tools#Cycle_collector_heap_dump

I would do it myself, but the edit page doesn't seem to be loading properly at the moment.

Comment 40

[Andrew McCreight [:mccr8]]

Oh, I guess the existing directions are correct, but maybe mentioning that you can just hit a direct key combo instead of dealing with about:config would be good.

Comment 41

[Jared Wein [:jaws] (please needinfo? me)]

The patches for this bug are in the process of being backed out by bug 798925. Tracking multiple landings in one bug are not ideal either, but it would be worthy to note for those CC'd to this bug that this change is being delayed until a better solution can be determined.

Comment 42

[John Drinkwater (:beta)]

Comments in Bug 798925 seem to indicate this is WONTFIX, yet in Bug 852490 removing the ‘Error Console’ menu item would be worth it considering how long the web developer menu is now… 
Is this still wanted? Could a ‘Gecko error console’ be linked to from the about:support page?

Comment 43

[Justin Dolske [:Dolske]]

Bug 816325 is about figuring out the UX for browser/addon devtools. Many of the current devtools are actually suitable for both webpages _and_ chrome, and then there's stuff like the Error Console which is more useful just for chrome (or at least should be, any webconsole bugs not withstanding).

Comment 44

[Mihai Sucan [:msucan]]

At this point this bug only depends on bug 859756 which has patches reviewed and landed in fx-team (which means it will land in m-c really soon). There are no other known blockers preventing this bug to be fixed - if you know one, please ping us.

As agreed with robcee and as announced on the firefox-dev mailing list we will flip the switch for the Error Console, to replace it with the Browser Console. I will attach a patch for review.

Bug 816325 is about the bigger picture - the browser debugger and any other devtools we can get to work with chrome code.

Comment 45

[Ben Bucksch (:BenB)]

As said before (e.g. comment 36), please first mature the alternatives, including browser and extension debugging, before removing this. CTRL+SHIFT+J helps a lot, though.

Comment 46

[Mihai Sucan [:msucan]]

Attachment: proposed patch

This patch does what was announced on the firefox-dev mailing list:

1. disable the Error Console by default. You can enable it by setting devtools.errorconsole.enabled to true in about:config.

2. enable the Browser Console by default. Reasoning for this was discussed in this and related bugs - the Error Console was enabled by default because it was the main place where users can copy/paste browser errors from - useful for troubleshooting.

3. change the ctrl/cmd-shift-j keyboard shortcut to open the Browser Console (it was used by the Error Console). Many users have muscle memory for this (I do too). It makes sense, I believe, to get existing users to work with the new Browser Console.

Please let me know if you have any concerns. Thank you!


Try push:
https://tbpl.mozilla.org/?tree=Try&rev=3fc09909469d

Comment 47

[Dave Townsend [:mossop]]

(In reply to Ben Bucksch (:BenB) from comment #45)
> As said before (e.g. comment 36), please first mature the alternatives,
> including browser and extension debugging, before removing this.
> CTRL+SHIFT+J helps a lot, though.

We believe that the browser console is a mature alternative. If there are specific things it doesn't do that you think are necessary then please file bugs on them and mark them as blocking this bug. Now at the start of the cycle seems to be a good time to make the change and see what issues come up.

Comment 48

[Dave Townsend [:mossop]]

Please only land this on fx-team so it gets to m-c along with bug 859756

Comment 49

[Dão Gottwald [:dao]]

Comment on attachment 751112 [details] [diff] [review]
proposed patch

>--- a/browser/locales/en-US/chrome/browser/browser.dtd
>+++ b/browser/locales/en-US/chrome/browser/browser.dtd
>@@ -209,21 +209,21 @@ These should match what Safari and other
> <!ENTITY webDeveloperMenu.label       "Web Developer">
> <!ENTITY webDeveloperMenu.accesskey   "W">
> 
> <!ENTITY devtoolsConnect.label        "Connectâ¦">
> <!ENTITY devtoolsConnect.accesskey    "e">
> 
> <!ENTITY errorConsoleCmd.label        "Error Console">
> <!ENTITY errorConsoleCmd.accesskey    "C">
>-<!ENTITY errorConsoleCmd.commandkey   "j">
> 
> <!ENTITY remoteWebConsoleCmd.label    "Remote Web Console">
> 
> <!ENTITY browserConsoleCmd.label      "Browser Console">
>+<!ENTITY browserConsoleCmd.commandkey "j">

It looks like this lacks an access key, unlike all other items in the Web Developer menu.

Comment 50

[Mihai Sucan [:msucan]]

(In reply to Ben Bucksch (:BenB) from comment #45)
> As said before (e.g. comment 36), please first mature the alternatives,
> including browser and extension debugging, before removing this.
> CTRL+SHIFT+J helps a lot, though.

Please do note that we are only replacing the error console with the browser console. The browser debugger is a separate feature which is unrelated to the error console. If we are missing anything, please file bugs.


(In reply to Dave Townsend (:Mossop) from comment #48)
> Please only land this on fx-team so it gets to m-c along with bug 859756

Thank you for the r+! That's the plan.

Comment 51

[Ben Bucksch (:BenB)]

> 3. change the ctrl/cmd-shift-j keyboard shortcut to open the Browser Console (it was used by the Error Console)

Strong objections. Please do not take that last access point away. I don't care whether you change error console to another letter, e.g. CTRL-SHIFT-E for error console and CTRL-SHIFT-J for browser console, but it must be easily accessible with a simple keystroke.

> We believe that the browser console is a mature alternative.

Not for extension development (including QA, and end users on the phone with problems)! Not adequate at all.

Comment 52

[Mihai Sucan [:msucan]]

Attachment: added accesskey

I will probably land the patch tomorrow. I'm going to wait for a green try push - I don't want to have surprises.

Comment 53

[Mihai Sucan [:msucan]]

(In reply to Ben Bucksch (:BenB) from comment #51)
> > 3. change the ctrl/cmd-shift-j keyboard shortcut to open the Browser Console (it was used by the Error Console)
> 
> Strong objections. Please do not take that last access point away. I don't
> care whether you change error console to another letter, e.g. CTRL-SHIFT-E
> for error console and CTRL-SHIFT-J for browser console, but it must be
> easily accessible with a simple keystroke.

Ctrl-Shift-E is used by Panorama, afaik. Also, what is the point of having two tools that do the same?

> > We believe that the browser console is a mature alternative.
> 
> Not for extension development (including QA, and end users on the phone with
> problems)! Not adequate at all.

Please elaborate. What is the browser console missing for extension developers, QA and end users?

Comment 54

[Ben Bucksch (:BenB)]

Errors (and debug output) happening in extensions

Comment 55

[Dave Townsend [:mossop]]

(In reply to Ben Bucksch (:BenB) from comment #54)
> Errors (and debug output) happening in extensions

Should be fixed by bug 859756. Once these have landed if you have specific problems please file bugs with steps to reproduce.

Comment 56

[Ben Bucksch (:BenB)]

Before replacing a central tool with another one that's not even checked in, and nobody had the chance to test in reality, with new profiles during dev, with QA, with end users on the phone etc., can we please wait a few releases for feedback and bug reports from devs?

Comment 57

[Ben Bucksch (:BenB)]

There's no good reason to remove the keyboard access, unless you want to actively destroy workflows.

Comment 58

[Dave Townsend [:mossop]]

(In reply to Ben Bucksch (:BenB) from comment #56)
> Before replacing a central tool with another one that's not even checked in,
> and nobody had the chance to test in reality, with new profiles during dev,
> with QA, with end users on the phone etc., can we please wait a few releases
> for feedback and bug reports from devs?

We're replacing it in Nightly builds. We have 17 weeks to gather testing and feedback before this hits releases. If in that time we find issues that can't be solved then we can back this out.

Comment 59

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 751128 [details] [diff] [review]
added accesskey

I appreciate that the Error Console is a "central tool" for you, but please try to appreciate the possibility of different perspectives.

No one is trying to "actively destroy workflows"; making those accusations really isn't productive.

The Browser Console in general has been landed for a while. The specific fix you seem to be concerned about will land before this one does, as mentioned in comment 55. We're not air-dropping this into the release channel - the Nightly channel exists specifically to get the kind of feedback you're suggesting we get, and there's plenty of time to address any issues you might have with the new tool.

Comment 60

[Mihai Sucan [:msucan]]

I would like to mention that the Browser Console was in nightlies for some time already. It is in Aurora now, and people will have a full aurora - beta - release cycle to get used to the Browser Console. Now we will land this Error Console replacement patch which will also follow the nightlies - aurora - beta - release cycle, before all users get the new behavior. This should be sufficient time for people to get used to it, report any serious bugs and so on.

If we keep the Error Console keyboard shortcut people will continue to use it and the Browser Console will not get the testing we want.

Ben, we also announced this plan on the firefox-dev mailing list, including the timeframe of the changes. People had time to discuss and voice their concerns. If we find serious bugs / blockers, we can backout this patch in aurora.

Comment 61

[Ben Bucksch (:BenB)]

> People had time to discuss and voice their concerns.

I did, in comment 36.

I understand the wish to have the new code tested.

Any objections to adding an alternative, similar keyboard shortcut for Error Console until the replacement is proven to work well in practice?

Comment 62

[Dave Townsend [:mossop]]

(In reply to Mihai Sucan [:msucan] from comment #50)
> (In reply to Dave Townsend (:Mossop) from comment #48)
> > Please only land this on fx-team so it gets to m-c along with bug 859756
> 
> Thank you for the r+! That's the plan.

And it should go without saying that now bug 859756 has been backed out this shouldn't be landing until that is fixed.

Comment 63

[Dave Townsend [:mossop]]

(In reply to Ben Bucksch (:BenB) from comment #61)
> > People had time to discuss and voice their concerns.
> 
> I did, in comment 36.

As far as we can tell we've addressed all your concerns from comment 36, the new browser console will show everything that the old one did, be more filterable and even easier to copy information from. Again if there are more issues that we've missed then I invite you to file specific bugs about them so that we can address them. You know how it works, we can't fix things unless you tell us exactly what is broken.

> Any objections to adding an alternative, similar keyboard shortcut for Error
> Console until the replacement is proven to work well in practice?

This doesn't seem like the right way to go, keyboard shortcut bloat is already a problem, even finding a new keyboard shortcut that doesn't conflict with a common add-on is an exercise in futility these days and I wouldn't want to spend localiser time on that.

Instead let's do this. Get bug 798925 landed and shipped in nightlies to give people a full chance to play with it. Then after a few days we can look at what bugs have been filed and make a decision on when to land this

Comment 64

[Ben Bucksch (:BenB)]

Sorry, I have to apologize. I was under the assumption that Browser Console = Web Console, which is wrong. Once bug 859756 lands, I'll try it out, see whether that works for XUL extension and xulrunner development and debugging in practice in the field. (I'll need weeks, though, not days.)

Comment 65

[Mihai Sucan [:msucan]]

Landed in fx-team:
https://hg.mozilla.org/integration/fx-team/rev/e0ed2a79d290

Comment 66

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/e0ed2a79d290

Comment 67

[Jorge Villalobos [:jorgev] (he/him)]

Bringing these flags back.

Comment 68

[bhavana bajaj [:bajaj]]

Unified console in changed section of release notes.

Comment 69

[Ioana (away)]

Verified as fixed on Firefox 24 beta 1 (20130806170643): the Error console is gone from the menu. The only consoles left are the Browser and Web consoles.