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...
mass move, v2. qa to me.
QA Contact: tever → benc
Summary: [RFE] Need network errors to go to non-blocking list or display → [RFE] Need network errors to go to non-blocking list or display (console)
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
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).
I really liked that tabbed idea!
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.
The only issue I see here is whether this tabs will be on future NS branchs.. :)
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
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
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
Summary: [RFE] Need network errors to go to non-blocking list or display (console) → Need network errors to go to non-blocking list or display (console)
-> defaults Cleaning up error handling bugs. Also might be good to integrate w/ logging features.
Assignee: new-network-bugs → darin
Summary: Need network errors to go to non-blocking list or display (console) → Network Console (errors, logging, etc)
*** Bug 98831 has been marked as a duplicate of this bug. ***
Assignee: darin → nobody
QA Contact: benc → networking
Target Milestone: Future → ---
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.)
this is the realm of devtools
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.