Open Bug 47128 Opened 25 years ago Updated 1 year ago

Display JavaScript error indicator in status bar

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: tim, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

Code for displaying JS errors in status bar
6.80 KB, patch
Details | Diff | Splinter Review
Related skin modifications
2.97 KB, patch
Details | Diff | Splinter Review
jserror.gif, statusbar error image
885 bytes, image/gif
Details
Mozilla should display an icon and message in the status bar indicating that a JavaScript error has occurred, similar to Internet Explorer, i.e. [(!) An error has occurred on this page. Double click for details.] ben@netscape.com has already partially implemented this (the java console listener is hooked up), but it's currently commented out because the console listener fires for chrome javascript errors too. I have a workaround for this that catches the "error" event fired by the content DOM. Other than that, there are a few other minor issues to address for this... - How long should the icon/message be displayed? Obviously it should go away when the current page is unloaded, but how should it interact with other statusbar information? I think the error message should probably be displayed whenever "Document: Done" would otherwise be displayed, so that the statusbar still works for hyperlinks. - The icon. Right now I just copied IE's. Not good :) Anyone have a good tiny error icon? Who the heck makes the art for Netscape anyway? - Should a ToolTip with the error message / line # / source file, etc. be displayed when hovering over the statusbar? This would be convenient for page authors, and trivial to add. Assigning to self, since looking at Ben's bug count leads me to believe he won't have time to work on this. I have it mostly done anyway. I think this is important so errors with Mozilla's DOM are visible. (although I'm sure there will be plenty of non-standard IE DOM errors too...)
Tim, could you combine this with bug 47108? (Please?:-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
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.
The above patches add a JavaScript error indicator in the statusbar when content errors occur. The error message is displayed wherever the normal "Document: Done" message would otherwise be displayed. jserror.gif is the icon used for this, and should be placed in both mozilla/themes/classic/communicator, and mozilla/themes/modern/communicator (I'm not sure how I add binary files with CVS...) Hopefully my artwork is satisfactory. cc'ing Brendan for approval.
Keywords: patch
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.)
MozillaClassic would say: JavaScript error: Type 'javascript:' into Location for details which is better than just reporting that the page contains errors -- note that classic had no Task menu item for the JavaScript console, and the only way to bring up the JS console was to type 'javascript:' into Location. Since we can do better in Mozilla, something about the JS console task menu item would do better, but I'll leave that wording exercise up to the experts. Document: Done always seemed silly to me, too. Dare we break with tradition and user expectations? /be
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...
QA Contact: mpt → zach
Keywords: mozilla0.9
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).
re-ccing mpt
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...
Blocks: 84128
No longer blocks: 84128
Has this bug died? I think resolutions to this bug (along with other page error/html quality bugs) are critical to Moz 1.0.
I'm not sure what this bug has to do with Mozilla 1.0, but fixing it would make it much easier to test and debug javascript using Mozilla. We have much better js error messages than the other browsers I've tried, but we don't tell programmers or users when the script encounters an error. I often find myself opening the javascript console to find out *whether* there was an error or not.
*** 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.
An error message in the status string shouldn't override other messages, but clickable error indicator with the most recent error as a tooltip should be always visible until JavaScript console will be cleared. Right click on this indicator should give an option to clear JavaScript console, and, may be, show all the details about the most recent error.
Blocks: 102402
Keywords: mozilla1.0, nsbeta1, review
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.
Keywords: nsbeta1 → nsbeta1-
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).
Blocks: 142458
*** Bug 160415 has been marked as a duplicate of this bug. ***
*** Bug 162494 has been marked as a duplicate of this bug. ***
.
Assignee: tim → blaker
Status: ASSIGNED → NEW
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → paw
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... jonasj@jonasj.dk changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|tim@prismelite.com |blaker@netscape.com Status|ASSIGNED |NEW Component|User Interface Design |XP Apps: GUI Features QAContact|zach@zachlipton.com |paw@netscape.com
Following on from Jesse and Alexander's comments, it appears to me that: * Having a popup all the time would be awful. * Not knowing if there are any errors unless we open the javascript console to find out whether an error has occurred at all, as things are now, is tedious. * Overwriting the status bar text is unpleasant I suggest that a small error icon of some sort in the status bar would be best, which would take the user to the javascript console if clicked on
Yes, you are right. And, in addition 1) tooltip on this indicator should contain latest error summary 2) context menu should contain some options like Show JavaScript Console, Disable JavaScript, Disable JavaScript For This Page Only, Run JavaScript Debugger, Clear JavaScript Console 3) this indicator should be optional (Preferences->Scripts & Plugins->JavaScript error indicator->Show indicator/Show message in statusbar)
Wouldn't it be nice to strip out most of the features no one is sure if it should be an error message or not. Then start with the basic, like the ability to display the JS error. Then check it in to the Mozilla trunk. Over the time, add some features, like javascript syntax error for starter and then add more features over the time. It's not like that it will be done overnight and be ready to go. Just little at a time. The Venkerman (spelling) Debugger doesn't feel right and this alternative is much nicer.
*** 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.
I support the last comments: this bug currently is "Display JavaScript error indicator in status bar". First, make it optional, not to bother the end-users; Second, start with something as simple as possible, only not to have to check the JS.C. regularly to see whether or not something happened. I am not a javascript/page developer, I'm only interested in Mozilla's (chrome/etc) issues: opening the JS.C. in the background and make it blink for attention would be enough to start with. (Well, that's at least a Windows point of view...)
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 ??
I believe that this is key to expand the adoption of Mozilla browsers to a large scope of end users: so many sites are still unaccessible to Mozilla because of poor javascript coding and DOM compliance issues, users neeed a way to figure out immediatelly and easily that an error has occurred, preventing them to experience correctly the site they are currently browsing. Without such highlight mecanishm, they will just conclude that Mozilla or Firefox doesn't work (or they don't know hos to use it properly), and will stop using it. A third party extension isn't the right answer for such audience: extensions are for advanced users (unless some sort of ready to use packaging of extensions is done by the Mozilla organization towards certain types of users)
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.
Assignee: firefox → guifeatures
This is a mozilla bug as stated in comment #1, not firefox.
Product: Core → Mozilla Application Suite
See also bug 400783, same bug for Firefox.
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: pawyskoczka → guifeatures
Priority: P3 → --
Component: XP Apps: GUI Features → UI Design
(In reply to Olivier Vit (just a reporter) from comment #41) > I believe that this is key to expand the adoption of Mozilla browsers to a > large scope of end users: so many sites are still unaccessible to Mozilla because > of poor javascript coding and DOM compliance issues, users neeed a way to figure > out immediatelly and easily that an error has occurred, preventing them to > experience correctly the site they are currently browsing. > Without such highlight mecanishm, they will just conclude that Mozilla or > Firefox doesn't work (or they don't know hos to use it properly), and will > stop using it. I as a developer also unnecessarily often keep bumping into a situation where I don't spot that the reason for some malfunction X is a JS error, before actually remembering to open Console and check. Smallish laptop screens simply don't permit having the console open all the time. Last activity seems to be in 2008. This seems to indicate most people interested have some kind of an other solution to this problem external to core products (FF, SeaMonkey, etc)?
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.

MY MAC's javascript doesn't work? Does anyone know how to fix this?

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: