Tim, could you combine this with bug 47108? (Please?:-)
I just thought of something to enhance this. What if special error messages were displayed for some errors. For example... "document.all has no properties", "document.layers has no properties" would show "An error has occurred on this page. This page uses non-standard extensions." on the statusbar instead of the normal error message. Adding this might reduce some of the false bug reports and blame Mozilla gets for causing errors which are due to non-standard extensions. I don't have a lot of experience with cross-browser scripting so I'm not sure what the most common JS errors are (ccing ekrock, maybe he knows). This won't catch everything, since faulty OR non-standard code can sometimes cause the same error.
Tim, please don't try to cram the error message into the status bar. Put it into a dialog instead (activated by clicking the icon). That way it won't get unavoidably cropped if I'm stuck on a low-res display. Just say `Done, but contains errors'. (Change that silly `Document: Done.' to `Done', while you're at it.)
Split off the "Document: Done" issue as bug 48436...
Oops, by error message I meant the generic error message, which Ben currently has set at "An error has occurred on this page. Double click here for details." I also display the specific JS error message in a tooltip, and you can double click the status bar to bring up the JS Console. There are actually three cases which the error message has to account for: - During Page Load - End of Page Load - After page load An error that occurs during page load might display for a brief moment before being overwritten by other status information (i.e. "Transferring..."), although the error icon remains. The end of the page load would be the only appropriate place to display a "Done, but with errors" type message. Then, after a page has loaded, a user might click on something that causes a JS error. Right now the same error message is displayed for all cases. It's probably a good idea though to have two separate error messages, one for on page load and the other for during/after page load. And it should indicate how to access the JS console. - Done (An error has occurred. Double click for details.) - An error has occurred. Double click for details.
Why is it a double click? Why not a single click?
If it's single click, I suggest it have some kind of hover effect (presumably like the ones that personal toolbar items for win32/mac classic have -- blue underline on hover)
What what what? I was talking about the icon. The text shouldn't be clickable at all -- just like any other status text.
Maybe it would become bright red on hover. It's pretty small for hover effects, though.
So is this patch ready to go...?
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
Since it's hard to get the cursor over a status bar button, I'd like to be able to make the JS console come up by double-clicking anywhere in the status bar when an error message is shown. There should be different icons for errors and warnings, each similar to the JS console icon. I think the icon shown should be for the most recent error/warning that applies to content in the window. Should messages be included, in addition to errors and warnings? Two examples of messages: - "The link to file:///c|/ was blocked by the security manager. Remote content may not link to local content." (from bug 40538) - "Deprecated method document.getSelection() called. Please use window.getSelection() instead." I think the file:/// message should show up but the document.getSelection() message shouldn't. In that case, perhaps the file:/// message should be upgraded to a warning or error (as a separate bug).
When there's a script error, it should display "Error on page" like IE, and it shouldn't show the error that's happening. Why? Because otherwise people will think it's an error in the browser ("Gee, I wonder why they would think that?" he posts in bug #47128...). For the same reason, I think the JS console should say the name of the page on the error it caused, but that's another bug that I'll write sometime...
Has this bug died? I think resolutions to this bug (along with other page error/html quality bugs) are critical to Moz 1.0.
*** Bug 115584 has been marked as a duplicate of this bug. ***
Random thought: Maybe the behavior should be different whether there is an error or a warning. Some users will want to see the warnings, some won't, some won't want to see any errors at all. This might involve a little pref work but keeps everyone happy.
When strict warnings are enabled, warnings are treated by the DOM as errors. That pref will do just nicely here I think -- no additional prefwork needed.
As there hasn't been any visible activity on this bug for a while, I'm wondering as to status here. The reason I said this is 1.0 critical (as it is marked in keywords) is evangelism, as in comments 2 & 19- if users see that the site's JS is to blame, we can make a big difference in how much JS coders think about the idea of standards compliance and avoid a lot of unnecessary bug triaging (reassigning bugs to evangelism every time a user finds a page with incompliant JS).
nsbeta1- per ADT triage.
Two additions: 1. I think that error messages too often appear instead of other text, such as page loading progress comments ("Resolving host..." "Waiting for reply...") or link URLs. So, there should be an option to switch between "JS error" and other text in the statusbar (like there is an option to open and close sidebar or toolbars). ... Ordinary user could want to see loading/URL messages, and user who is studying JS or debugging JS in a page could want to see JS messages. 2. JS error indicator/button should display last error as a tooltip (if there were no errors, it should display last warning). May be, there could be Last JS Error toolbar (hidden by default).
*** Bug 160415 has been marked as a duplicate of this bug. ***
*** Bug 162494 has been marked as a duplicate of this bug. ***
I wonder if Jonas really meant to override the non-mpt assignment with the move away from the User Interface Design component. It looks like Tim Hill produced a patch, but that was two years ago and undoubtably no longer applies. Hmm... email@example.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTofirstname.lastname@example.org |email@example.com Status|ASSIGNED |NEW Component|User Interface Design |XP Apps: GUI Features QAContactfirstname.lastname@example.org |email@example.com
*** Bug 211806 has been marked as a duplicate of this bug. ***
Available as an extension http://extensionroom.mozdev.org/#jsstatus
"Available as an extension"... for firebird only.
Disregard my very last sentence: that would be bug 95898 :-< Having an icon, and single clicking it would be better than nothing ! Maybe, an optional sound could be added to alert the user ??
Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). If you want this fixed for Firefox, change the Product and Component accordingly and reassign back to me.
This is a mozilla bug as stated in comment #1, not firefox.
See also bug 400783, same bug for Firefox.
Filter "spam" on "guifeatures-nobody-20080610".
I for one am still having troubles with this. It is one of the few areas in which I think IE does a better job. I went looking for the addon mentioned here and that page link is no longer valid nor does the addon appear to be on AMO. I would like to give the addon a try as I was just going to try doing something like this myself and see no need to re-invent the wheel.