Provide a path to expose Error Console to users troubleshooting Firefox

NEW
Unassigned

Status

()

defect
9 years ago
4 years ago

People

(Reporter: zzxc, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: [wontfix?])

When bug 593538 was fixed, the Error Console became inaccessible to users troubleshooting problems with Firefox.  Helpers on support.mozilla.com often ask users for recent errors when troubleshooting certain types of problems, such as broken UI and misbehaving websites.

Since Error Console will not be available from the Firefox menu, support contributors need another way of getting this data from users.  We're already asking users to provide data from about:support, so this may be a logical place to include recent errors and/or a button for accessing the Error Console.
blocking2.0: --- → ?
Could you give us details about what sort of errors you'd want included there? I *think* it should be possible to do this in about:support, but want to know if you're just looking for recent errors (like, in the last hour) or errors, warnings, etc.
We only need errors - warnings and messages aren't usually needed for troubleshooting.  The about:support data should list the most recent errors along with timestamps.

The types of errors we most frequently use are:
*JS parsing and runtime errors (content and chrome)
*xpcom component errors/exceptions/failures
*DOM/security errors
*Errors from extension manager (when installing extensions)

Some error types we frequently use but don't have in error console are:
*Various errors from Sync log
*Most recent crash report IDs
*Unresponsive script

Events that are not errors but would be useful to include:
*Cookie blocked by an exception
*XHR, hidden iframe POST, or npapi network errors.  (SSL, connection timed out, etc)
Matthew - even with the pref off, you can access the error console with the keyboard shortcut (Ctrl-Shift-J). Is it essential enough to have this in troubleshooting info for us to break string freeze to get the section header in?

Speculatively marking this blocking- in the hope that accel-shift-J is good enough?
blocking2.0: ? → -
(In reply to comment #3)
> Matthew - even with the pref off, you can access the error console with the
> keyboard shortcut (Ctrl-Shift-J). Is it essential enough to have this in
> troubleshooting info for us to break string freeze to get the section header
> in?

Really? With the pref turned off the shortcut doesn't work with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20100922 Firefox/4.0b7pre

Johnathan, given your comment I should file this as new bug and ask for blocking?
The shortcut doesn't work when the menu item is missing on Linux or Windows, either.  Relying on a keyboard shortcut makes troubleshooting much more difficult for users, so we would really like a menu path to get this information.

An "Error console" button inside the about:support page would provide us with the same functionality as Firefox 3.x without introducing new strings.  Listing the errors on the page would be even simpler for users, but our main concern is that we avoid regressing troubleshooting functionality from 3.x.  User experience gains are always appreciated, of course :)
Any update on a plan for this?  Making the shortcut work even without the matching menu item would suffice for troubleshooting documentation, albeit with added complexity.  (Since not all users know how to use keyboard shortcuts, we have to explain holding down multiple keys at the same time)

Some error messages in Firefox, such as the -203 installation error in extension manager, tell users to "check the error console" for details - so we'd really like this to remain somehow discoverable.  It's currently our main method for diagnosing corrupt files in the profile folder, extension manager breakage, and primary UI issues due to add-ons.
bug 601201 would return the shortcut ... by returning the menuItem :)
Proposing wontfix since the error console is available in the menu again.
Whiteboard: [wontfix?]
You need to log in before you can comment on or make changes to this bug.