Closed Bug 602006 Opened 10 years ago Closed 8 years ago
Remove Error Console Menu Items
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.
blocking2.0: --- → beta8+
10 years ago
Does this actually need to block beta 8? Or can we have it block betaN, and take it opportunistically if ready?
Though I think this will get into beta8, based on how things are going, I'm fine with calling it a betaN blocker.
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.
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).
(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. :)
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...)
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.
blocking2.0: beta8+ → ?
mass change: filter mail on BLOCKERSETTING
Severity: normal → blocker
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?
Attachment #493993 - Flags: review?(dtownsend)
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 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.
Attachment #493993 - Flags: review?(dtownsend) → review+
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!
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.
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.
(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 and possibly the help page as well. : https://developer.mozilla.org/en/Using_the_Web_Console : https://developer.mozilla.org/AppLinks/WebConsoleHelp?locale=en-US
Summary: disable Error Console again once Web Console improvements land → Remove Error Console Menu Items
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?
Hiding menu options, while leaving the command enabled.
(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.
Is this the right patch? I don't understand what it's trying to do.
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.
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.
No longer blocks: devtools4
blocking2.0: betaN+ → ---
Comment on attachment 510651 [details] [diff] [review] error console key This patch kills support for the hidden pref.
Attachment #510651 - Flags: review?(dtownsend) → review-
UX said it wasn't necessary.
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).
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?
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.
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.
Assignee: rcampbell → jaws
Attachment #510651 - Attachment is obsolete: true
Attachment #632136 - Flags: review?(dao)
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.
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.
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.
Case in point: it doesn't show the GC log information...
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.
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.
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.
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
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 18
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.
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.
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.
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?
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).
Depends on: 816325
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.
Assignee: nobody → mihai.sucan
Depends on: 859756
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.
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
(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.
Attachment #751112 - Flags: review?(dtownsend+bugmail) → review+
Please only land this on fx-team so it gets to m-c along with bug 859756
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.
(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.
> 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.
I will probably land the patch tomorrow. I'm going to wait for a green try push - I don't want to have surprises.
(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?
Errors (and debug output) happening in extensions
(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.
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?
There's no good reason to remove the keyboard access, unless you want to actively destroy workflows.
(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 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.
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.
> 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?
(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.
(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
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.)
Status: REOPENED → ASSIGNED
Target Milestone: Firefox 18 → ---
Landed in fx-team: https://hg.mozilla.org/integration/fx-team/rev/e0ed2a79d290
Status: ASSIGNED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
Unified console in changed section of release notes.
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.
Status: RESOLVED → VERIFIED
5 years ago
Depends on: 1258985
You need to log in before you can comment on or make changes to this bug.