80293 - Network Console (errors, logging, etc)

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[benc]

From Bug 74331:

I think what is needed is an error mode (that should be prefs pickable), that
creates a error list window. Errors would get sent to it (the way vacation
messages pile up in AIM...), but would be non-blocking, not waiting for user
confirmation.

For my purposes, this would ideally over-ride all the other types of error
behavior we have discussed in various bugs (send to a page, send to a dialog,
display broken icon for missing inline graphic, etc).

Power users and network analysts would love this feature because it gives them
total visibility to what network problems occur.

It would also be great for ibench and browser buster testers, because
intermittent errors would not lock up the test until a human clears the error
dialog.

My thinking here is that our current error handling reflects a misunderstanding
about errors needing blocking network access. Most network errors are transient,
and they do not actually block further network access. They do however, block
the user experience, because you assume that the browser was pulling something
that a user wanted to see.

There are some potential problems (like infinite errors logged when a router
goes down w/ a continuous test), but I think these could be worked out...

Comment 1

[benc]

mass move, v2.
qa to me.

Comment 2

[[not reading bugmail]]

Pasting my own message here from bug 28586:

Try 1)


Take the history Sidebar, rename it something like inaccessable DNS site.. 

(history already updates and keeps track of dns entries for sites you visit)

Hack the code so that you can change a pref to make the dialog box info update
into the sidebar instead

new sidebar should show site, erronous DNS errors that are normal dialog
popups.. like cannot connect to site X, with seperator for other types of error
blocks like: Events, Alerts, Warnings, DNS errors.. add pref to send the code
that would event the dialog box to update the sidebar like history does already.
 smaller box that displays the message once you click on the listed site and
error that it occured on.. it would update the lower box with the message that
an error or alert would give you. a generic one.


and you can take care of the error by just clicking on like how the messages
keep track of read/unread by click or by keyboard navigation over the error.

--------------- ie:

"I think what is needed is an error mode (that should be prefs pickable), that
creates a error list window. Errors would get sent to it (the way vacation
messages pile up in AIM...), but would be non-blocking, not waiting for user
confirmation.

For my purposes, this would ideally over-ride all the other types of error
behavior we have discussed in various bugs (send to a page, send to a dialog,
display broken icon for missing inline graphic, etc)."

-------------------

..  walla... we have a error page and no more dialogs.. and I can click on them
anytime.

which all leads to a better end-user experience!!

Try 2)

Or, we could hack the JS console and the dialog event/alert/warning handler to
send the messages to the new Website Error Console.  The JS Console does the
same thing as it also keeps track and dumps to the console when there is an error.
We have a error console and no more dialogs.. and I can click on them anytime.

:)


I'd prefer either solution as long as we can produce something here to cut down
on having to click on pop dialog messages that are useless for useless info,
that I wouldn't of noticed if it had not come up, because everything appears to
work for what I went to that page for.


-dman84

Comment 3

[Adam]

I think it should be done just as it is in emacs or quake.

both of those have special separate "console" For messages (in emacs it is
"Messages") buffer, and in quake you get it by pressing "~".

I think that that any message which does not require user intervention (ie just
click "OK") should go to that console. It is annoying to have to click on could
not connect to host this, could not connect to host that or whatever.. (many web
pages today are composed of parts of coming from muliple hosts, so I should not
have page redering halted just b/c one of those hosts is not available).

since mozilla supports tabbed windows, this console could be just another tab,
with persistent contest.. and if i close it , it could just pop up back with new
message (and/or the tab itself could flash if the contest is updated).

Comment 4

[benc]

I really liked that tabbed idea!

Comment 5

[[not reading bugmail]]

combine the a tab window with dialogs popup messages.. with the incorporation of
not having to click on them at all, but just add them to the list like the
history tree, or JS console.  

Good thinking Adam.. and Ben.  I vote for this is how this bug should proceed.

Comment 6

[[not reading bugmail]]

The only issue I see here is whether this tabs will be on future NS branchs.. :)

Comment 7

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 8

[[not reading bugmail]]

ok, since tabs are going in.. this shouldn't be difficult.. but I just had a new
idea today now that download manager window is in that would be even better than
a tab error window.

We could just create a very similar window and have buttons that dismiss
errors.. but these errors would have severity ranges on them.. some would be for 
1) not interupting usage errors.. would stack up like download links do, users
can click on a dismiss error dialog button anytime.
2) ones that do interupt - needs a restart or something.. user has to dismiss,
if error is critical.. like we have in the severity list here.  it would bring
up the *error feedback manager*  to the front *like a dialog does now, and user
has to dismiss this error to keep working.

*we could just replace the code that sends calls to the dialog windows to call
the *error feedback manager* window, and pass in the severity of the dialog
error to the manager to decide if it should be a #1 or #2..

This makes more sense as you can easy have such a window open or not.. many
errors will follow under #1.  very few would be #2) but it maybe useful
nevertheless.  The user doesn't have to worry about switching tabs or content
stealing browser view like search does... *mpt* should be cc'd for input here.

-dennis

Comment 9

[[not reading bugmail]]

If that functionality is implemented, darin could get networking to send over
bug 131399 unknown errors: which could be send to this error manager* window and
have it pass in its moz code path or source of problem and severity in a way
that is mirrored by the Javascript Console window's strict warnings.. 

Comment 10

[Doug Turner (:dougt)]

moving neeti's futured bugs for triaging.

Comment 11

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 12

[benc]

-> defaults

Cleaning up error handling bugs. Also might be good to integrate w/ logging
features.

Comment 13

[benc]

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

Comment 14

[MOZZOLINO]

can not see this feature in 2013 - very annoying. Please take a look at Ritlabs TheBat, which implements an easily accessible errorlog in a very good way. (easy accessible protocol log window and last log line visible in status bar.)

Comment 15

[Patrick McManus [:mcmanus]]

this is the realm of devtools