312962 - Redesign Error Console for easier reading and visual scanning

Status: RESOLVED INCOMPLETE

(Toolkit Graveyard :: Error Console, enhancement)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

bug 291002 added icons and some CSS tweaks to make it easier to read the content
of the JS console, but a lot more could be done (both visually and functionally)
to improve things:
 
 - add filter UI (like in about:config) and support search (Ctrl+F)
 - add small icons to make it easier to scan message list visually
 - right align source-file and line info to make it easier to scan that
   set of information

A larger change would be to:

 - replace UI with a table widget that allows user to sort by
    -- message type {error|warning|message}
    -- message text
    -- source file name & line number

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: mockup of visual changes (without changing to table widget)

Quick mockup of some of the proposed changes

Comment 2

[Simon Bünzli]

Some random implementation related thoughts:
- search support (Ctrl+F): this should be discoverable somehow, either through a
toolbar button or a menu entry (should there ever be a menu in the toolkit's
console). Further on, marking the found text would have to be implemented for at
least <description> and <label> (error message and source file). Should this
ever be done, the same code might be useful for the Bookmarks manager as well.

- small icons: I'm not sure whether smaller icons help - they're less prominent
(especially now that the type label is gone), kind of get lost at the top when
there's source code in the entry (IMHO they might even make parsing harder,
since you've got no clean line to follow alongside the text), and they're less
extensible in case different error types should ever be marked as such visually
(JS/CSS/XML/etc).

- right align source file info: there are two options here - either the host is
more important, or the file name is. Should it be the first, scanning is
obviously easier if the URL is left-aligned (what helps already is that URLs are
in a different color). For the second option, in case of overlong URLs would it
not only be necessary to crop the host part away, but the cropping would have be
to be clever enough to drop unimportant parts of the query string (so that the
filename is still visible) while keeping the important parts (since e.g.
index.php in a CMS could be as good as any page). (see also bug 291002 comment #30)

- replacing the UI with a table/tree: conceptually this would be a great idea.
Unfortunately there are three important parts of the error message which all
need to be layed out horizontally: message, source file and source code (and in
the future maybe also the stack trace). To stick them aside each other might
render the console less readable. Additionally, there must be a fourth way of
sorting: time of occurrence. This information so far isn't provided (see bug
228205 for the work on that). It is however most important, since the order of
errors can also contain important information. Therefore I'd optionally go with
sorting, not however with the altogether different UI.

Comment 3

[Jon Henry]

See also bug 310168, which could help solve some of the JS console's usability problems for free.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Thanks, Jon: I'm tempted to add a dependency!

Comment 5

[Mike Connor [:mconnor]]

*** Bug 310168 has been marked as a duplicate of this bug. ***

Comment 6

[bugzilla]

Attachment: Console² screenshot

Comment 7

[Mel Reyes]

Someone should seriously consider syncing up with zeniko to merge his great work with Console² into this effort or even just replace any existing efforts.

http://forums.mozillazine.org/viewtopic.php?t=318102

just my lame arc 2 cents.

Comment 8

[Simon Bünzli]

It'd be nice to see a somewhat more specific design of how the redesigned console should look like. With that I could offer you to submit either patches to all the bugs Console² claims to fix (currently http://tinyurl.com/l3zdf ) or an über-patch for this bug - should you really want to (mainly) include a part of Console²'s enhancements. Mike?

Comment 9

[Bill Gianopoulos [:WG9s]]

We also have 2 extensions with 2 different redesigns of the error console.  The second one being Firebug.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Adding swag, with apologies for blocking on this for so long :(

Comment 11

[Mike Connor [:mconnor]]

pushing out non-critical-path bugs to b2

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

OK, so we'd be willing to take safe XUL and CSS changes here for the beta2, but nothing that requires new functionality. With respect to attachment 209326 [details], some comments:

 * the clear button should use the current icon from the error console
 * search/filter options should be in the same place, not split between the upper right and the button row
 * we need a different set of images for "depressed button" state - right now it looks like hover, and if we're switching these buttons to be able to have 1..n depressed, that's gotta change

Comment 13

[Simon Bünzli]

A sad decision to let Firefox' once so great console become second class to Opera's. Could you please take the time for going through the list I posted ( http://tinyurl.com/l3zdf ) and judge which of these might still have a chance on their own?

(In reply to comment #12)
>  * the clear button should use the current icon from the error console

It actually does.

>  * search/filter options should be in the same place, not split between the
> upper right and the button row

Not sure I understand what you mean but what you see below the button row is the JavaScript evaluation field, not a filter.

>  * we need a different set of images for "depressed button" state - right now
> it looks like hover, and if we're switching these buttons to be able to have
> 1..n depressed, that's gotta change

It looks almost like hover - but that's an issue with all checkbox toolbar buttons (of which these are very common examples).

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #13)
> A sad decision to let Firefox' once so great console become second class to

People can still install your extension, so its not a total disaster :) I'm not overly concerned about fighting Opera for the "I want my web browser to be an all purpose jacknife with 200 weebles and wobbles out of the box, please!" crowd. I leave that to SeaMonkey.

That aside, I didn't say we wouldn't do it. I said what it would take at this point to make it do it. I'm about forward motion here, if you're willing to work with our process on this.

> Opera's. Could you please take the time for going through the list I posted (
> http://tinyurl.com/l3zdf ) and judge which of these might still have a chance
> on their own?

As I said, drivers are taking small and safe patches that don't affect a lot of the rest of the code, are fixing existing bugs or performance issues, and that have baked on trunk for a couple of days to ensure we're not going to accidentally regress anything. From that list, the likely candidates for patches that would look like this are:

 - bug 81209
 - bug 175517 (seems invalid)
 - bug 238898, maybe, depends what code you end up touching
 - bug 272420
 - bug 291002 could be added to the dep-list for bug 328065
 - bug 305206
 - bug 307354

> (In reply to comment #12)
> >  * the clear button should use the current icon from the error console
> 
> It actually does.

I was going off the screenshot, where it uses an "X" instead of a page w/eraser as my build is currently showing.

> >  * search/filter options should be in the same place, not split between the
> > upper right and the button row
> 
> Not sure I understand what you mean but what you see below the button row is
> the JavaScript evaluation field, not a filter.

Yes, but to the left of that field are the buttons which are used to filter the various types of warnings, correct? What I'm saying is that those buttons should be more closely associated with the search/filter field.

 >  * we need a different set of images for "depressed button" state - right now
> > it looks like hover, and if we're switching these buttons to be able to have
> > 1..n depressed, that's gotta change
> 
> It looks almost like hover - but that's an issue with all checkbox toolbar
> buttons (of which these are very common examples).

It looks exactly like a hover, and it's bollocks that checkbox toolbar buttons are like that. Go take a peek at the Bookmark Manager; the depressed state (when you're holding the mouse down) is what these should look like when they are "checked".

Comment 15

[Simon Bünzli]

(In reply to comment #14)
>  - bug 81209

Should be simple once bug 305206 is fixed.

>  - bug 175517 (seems invalid)

Indeed, I probably misread the bug (I meant to prevent horizontal scroll bars from appearing whenever possible).

>  - bug 238898, maybe, depends what code you end up touching

That should be a one-line fix.

>  - bug 272420

Mainly a CSS fix.

>  - bug 305206

That's by far the biggest one of this list and means replacing the console widget with a standard richlist box. Are you sure that this isn't already too much for drivers to take at this stage?

>  - bug 307354

Again a pretty simple CSS fix.

> I was going off the screenshot, where it uses an "X" instead of a page w/eraser
> as my build is currently showing.

Let me guess: you're using a Mac? What you see on the screenshot are the Winstripe icons (cf. your attachment #200049 [details]).

> Yes, but to the left of that field are the buttons which are used to filter the
> various types of warnings, correct? What I'm saying is that those buttons
> should be more closely associated with the search/filter field.

I mimicked the position of the search field in other places in our UI. See e.g. Thunderbird's mailbox search. But that probably doesn't matter anyway, since this won't get in for Firefox 2.

> It looks exactly like a hover, and it's bollocks that checkbox toolbar buttons
> are like that. Go take a peek at the Bookmark Manager; the depressed state
> (when you're holding the mouse down) is what these should look like when they
> are "checked".

It doesn't. On Windows they currently do look exactly as on the screenshot. Just compare that screenshot with the first screenshot in this bug (attachment #200049 [details]). In fact, they shouldn't look the same in checked and pressed state so that you get visual feedback when you press an already checked button. Still, that's nothing which should be fixed in this bug anyway.

Comment 16

[Simon Bünzli]

(In reply to comment #15)
> (In reply to comment #14)
> Indeed, I probably misread the bug (I meant to prevent horizontal scroll bars
> from appearing whenever possible).

Not sure whether we/you really want that, since I haven't seen a bug about it (visit http://tinyurl.com/zupoo and see whether you feel like filing one).

> >  - bug 238898, maybe, depends what code you end up touching
> That should be a one-line fix.

Patch posted for review. If you know a valid reviewer not as overburdened as mconnor, please modify the review request.

> >  - bug 272420
> Mainly a CSS fix.

Seems to be WORKSFORME already.

> >  - bug 305206
> That's by far the biggest one of this list and means replacing the console
> widget with a standard richlist box. Are you sure that this isn't already too
> much for drivers to take at this stage?

I'd SWAG this as 2 days work. Might even be worth waiting for bug 298371 before tackling this. And I don't really feel like doing it myself.

> >  - bug 307354
> Again a pretty simple CSS fix.

Patch posted for review.

Furthermore bug 289927 is almost there as well (a year-old patch by doron which still applies but never has been checked in) and bug 306223 is already awaiting 1.8.1 approval.

Oh, and you might want to think about getting a new bug for the redesign - this one seems to have morphed into a 1.8.1 Error Console meta bug. ;)

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

Not going to block on this, but Simon, if you want to make some of those simple fixes that you pointed out, please do, get them landed on trunk and flag the patches approval1.8.1?

Comment 18

[Simon Bünzli]

I've posted patches for bug 86093, bug 238898 and bug 307354 (all "polish" bugs). These are awaiting review from mconnor (who's probably got better stuff to do). Anybody wanting to do the review for him, please go ahead.

Comment 19

[Simon Bünzli]

Mike: Any further plans for this bug? Still not willing to give Console² a chance? ;-)

Comment 20

[Unknown W. Brackets]

(In reply to comment #19)
> Mike: Any further plans for this bug? Still not willing to give Console² a
> chance? ;-)
> 

I use Console², but I do have to say that it's very very sluggish in operation...

-[Unknown]

Comment 21

[Nochum Sossonko [:Natch]]

So, some parts of this may be included in bug 489736 other parts I'll come back to with time. It would be great if a ui-mockup of the proposed new console can be made...

Comment 22

[Jesse Ruderman]

More likely is that the Web Console will continue to improve and take over from the Error Console, and then eventually the Error Console will be retired (bug 602006).