Closed Bug 593538 Opened 14 years ago Closed 14 years ago

Hide the Error Console behind a preference

Categories

(Firefox :: Menus, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 4.0b7
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: dangoor, Assigned: rcampbell)

References

(Blocks 2 open bugs)

Details

(Keywords: dev-doc-complete, relnote, Whiteboard: [kd4b6])

Attachments

(2 files, 4 obsolete files)

In Firefox 4, we plan to ship the new "Web Console" tool that helps developers troubleshoot content errors, which will meet the needs of most developers.

Firefox and add-on developers rely on the Error Console to debug chrome errors (after they've set the javascript.options.showInConsole = true pref). The existence of the Error Console next to the Web Console on the menu will be confusing to typical users.

There are three parts to this change:

1. Rename the Error Console to (bikeshed painting time): Browser Console, Chrome Error Console, Chrome Console

2. create a browser.enableChromeDeveloperTools pref which defaults to false and determines whether or not the Error Console appears in the menu. Ideally, the javascript.options.showInConsole value should be migrated into this new pref (so users that previously had it turned on will see the new menu item right away).

3. Remove the javascript.options.showInConsole pref


This needs to be done in beta 6.
blocking2.0: --- → ?
OS: Mac OS X → All
Hardware: x86 → All
Blocks: devtools4b7
taking...
Status: NEW → ASSIGNED
Attached patch Error Console Pref (obsolete) — Splinter Review
responds to: browser.devtools.errorconsole.enabled.

Browser must be restarted for changes to take effect.
Attachment #472685 - Flags: review?(gavin.sharp)
(In reply to comment #0)
> In Firefox 4, we plan to ship the new "Web Console" tool that helps developers
> troubleshoot content errors, which will meet the needs of most developers.
> 
> Firefox and add-on developers rely on the Error Console to debug chrome errors
> (after they've set the javascript.options.showInConsole = true pref). The
> existence of the Error Console next to the Web Console on the menu will be
> confusing to typical users.
> 
> There are three parts to this change:
> 
> 1. Rename the Error Console to (bikeshed painting time): Browser Console,
> Chrome Error Console, Chrome Console

I'd recommend Browser Console, I think. The menu options should be pretty distinct then, e.g., Browser Console vs. Web Console.

> 2. create a browser.enableChromeDeveloperTools pref which defaults to false and
> determines whether or not the Error Console appears in the menu. Ideally, the
> javascript.options.showInConsole value should be migrated into this new pref
> (so users that previously had it turned on will see the new menu item right
> away).

From my patch above, I created browser.devtools.errorconsole.enabled. I guess we could migrate this to browser.devtools.browserconsole.enabled.

> 3. Remove the javascript.options.showInConsole pref

tbd.
Attached patch Error Console showInConsole (obsolete) — Splinter Review
Removes showInConsole code and pref. No longer needed.
Attachment #472699 - Flags: review?(dtownsend)
Attached patch Error Console Rename (obsolete) — Splinter Review
Changed Error Console to Browser Console in browser.dtd. Left references in code as-is.
Attachment #472701 - Flags: review?(gavin.sharp)
Comment on attachment 472699 [details] [diff] [review]
Error Console showInConsole

I don't think we should be removing support for this pref from all applications. Seems like you just want to make Firefox default to true.
Attachment #472699 - Flags: review?(dtownsend) → review-
Attachment #472699 - Attachment is obsolete: true
Attachment #473049 - Flags: review?(dtownsend)
I think this is important to the webconsole being a successful (and unambiguous!) feature - marking this blocking beta6 so that we have a coherent story at feature freeze.
blocking2.0: ? → beta6+
Comment on attachment 473049 [details] [diff] [review]
Error Console showInConsole->true

I'm technically not a browser peer but I suspect this is fine
Attachment #473049 - Flags: review?(dtownsend) → review+
(In reply to comment #9)
> Comment on attachment 473049 [details] [diff] [review]
> Error Console showInConsole->true
> 
> I'm technically not a browser peer but I suspect this is fine

I figured since you did the first round on that piece, I'd just extend you the privilege. :)
blocking2.0: beta6+ → ?
Back you go, misplaced blocking flag
blocking2.0: ? → beta6+
Comment on attachment 472701 [details] [diff] [review]
Error Console Rename

Need to change the entity name when you make a semantic change to it.
Attachment #472701 - Flags: review?(gavin.sharp) → review-
None of the patches in this bug really make this a "browser console", so the string change seems kind of wrong - it still will be mostly filled with web content errors in the common case. Given that we're hiding it, how about we just leave the name as-is?
Comment on attachment 472685 [details] [diff] [review]
Error Console Pref

This will throw, since that pref doesn't have a default value. We should just associate both the menuitem and the key with a <command> element and just disable/enable that, too.
Attachment #472685 - Flags: review?(gavin.sharp) → review-
(In reply to comment #13)
> None of the patches in this bug really make this a "browser console", so the
> string change seems kind of wrong - it still will be mostly filled with web
> content errors in the common case. Given that we're hiding it, how about we
> just leave the name as-is?

The intention is to take care of bug 593540 soon as well, which will filter out the content errors from the Browser Console. (So, the Web Console is where you go for content errors...)
Well, we could get rid of that part of the bug. I kind of agree with Gavin that it's a pointless change to rename it in this case. It will still be an "Error Console".
I'm not attached to Browser Console. I don't mind if "Error Console" stays that way.
updated patch. Made the logic more like the inspector pref patch in bug 593536. Changed the pref to devtools.errorconsole.enabled to be more consistent.
Attachment #472685 - Attachment is obsolete: true
Attachment #472701 - Attachment is obsolete: true
Attachment #473049 - Attachment is obsolete: true
Attachment #473684 - Flags: review?(gavin.sharp)
Comment on attachment 473684 [details] [diff] [review]
[checked-in] Error Console Pref + showInConsole

same comment about .hidden/.disabled. Should probably get explicit ui-review on both of these as well.
Attachment #473684 - Flags: review?(gavin.sharp) → review+
Comment on attachment 473684 [details] [diff] [review]
[checked-in] Error Console Pref + showInConsole

http://hg.mozilla.org/mozilla-central/rev/2aaeb42e51a6
Attachment #473684 - Attachment description: Error Console Pref + showInConsole → [checked-in] Error Console Pref + showInConsole
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Depends on: 595096
Verified fixed using hourly build Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre from cset cca361001fda

The error console is hidden tools menu.  Flipping the pref to true and then restarting Firefox shows the menu entry.
Assignee: rcampbell → nobody
Status: RESOLVED → VERIFIED
Component: General → Menus
QA Contact: general → menus
Target Milestone: --- → Firefox 4.0b6
The keyboard shortcut doesn't actually get enabled. Please back out or fix quickly.
Assignee: nobody → rcampbell
Severity: blocker → normal
Status: VERIFIED → RESOLVED
Closed: 14 years ago14 years ago
Keywords: dev-doc-needed
will investigate...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I expect it has to do with setting .disabled = false instead of removing the attribute. I saw this with the inspector as well.
fix for key enablement
Attachment #474054 - Flags: review?(dietrich)
Attachment #474054 - Flags: review?(dietrich) → review+
Comment on attachment 474054 [details] [diff] [review]
[checked-in] Error Console Key

http://hg.mozilla.org/mozilla-central/rev/5c0a3f26e0ef
Attachment #474054 - Attachment description: Error Console Key → [checked-in] Error Console Key
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Flags: in-litmus?
Keywords: relnote
I updated the Menu Litmus test case to reflect this change and disabled the other test cases related to Error Console.
Flags: in-litmus? → in-litmus+
Verified with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6pre) Gecko/20100911 Firefox/4.0b6pre
Status: RESOLVED → VERIFIED
Version: unspecified → Trunk
This got documented when robcee's blog post went up a couple days ago.
Blocks: 596249
No longer depends on: 595096
Blocks: 596800
Blocks: 597842
No longer blocks: 601201
Depends on: 601201
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: