M3 AppRunner. 1) Go to that URL 2) After loading "javascript error: type javascript: in location bar ..." is displayed 3) type javascript: in location bar 4) "barber pole" in status bar spins forever, errors never displayed

Re-assigned to jband@netscape.com and changed component to JavaScript Debugger.

passing the buck - please reassign this as appropriate :) I don't know what M3 did with the URL above, but the build in my tree crashes after a few seconds while doing js_gc during timeout calls. Is this an otherwise known bug? Nevertheless, 'JavaScript Debugger' is not the appropriate target component for this bug. SeaMonkey currently has no schedule to support a JavaScript Debugger. The thing that 4.x did when one typed "javascript:" into the urlbar was open the JavaScript Console. This is a whole 'nother animal. I'm not seeing anything happen when trying to open the JavaScript Console. I know that viewer supports it as a menu item (but not as a "javascript:" url). 4.x implemented the "javascript:" url via an ugly hack in libnet. I don't know what the plan is for this in seamonkey (or whose task it is).

javascript: in general is busted right now. That could be part of this. javascript:'s are Vidur's land.

you'all gona make it for M4? Or should I Release Note. I need an 'M' here please?

Moved to M5.

Waiting for the new netlib before I rewrite javascript: URL processing.

Brendan, do you want to take this one as well?

Sure, thanks. /be

Moving to Javascript Engine component. Javacript component being retired.

I'm putting this in the netlib component, an imperfect fit, but closest. /be

Need Necko, so M9. /be

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

This can wait till M10. /be

I added nsIScriptContextOwner::ReportScriptError() so that script errors are propagated up. The current implementation simply prints to the console. This should either go to a JS console or (at least for beta 1) bring up an error dialog.

Ben's gonna help out with the console design and XUL. /be

M13 so we can do it when Ben gets in country. /be

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.

Have to push this out, Ben's not yet here. /be

While I'm on sabbatical, I'd like to leave this with Ben -- it'll probably fall off the priority triage list, but maybe he can do some UI brainstorming and mockups. Ben, I'll take it back when I return, and do the C/C++ side. /be

not for m14. need to discuss further w/brendan.

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

If there is some way of accessing the info that used to be displayed in the DOS window for Win9x/NT, someone please let me know! Otherwise, I would suggest raising the priority of this issue. I cannot very well help submit bug reports when my pages do not finish loading as a result of javascript errors that I cannot see. The js errors I'm sure are a result of nonconformity with your DOM, but I can't make them conform if they are not reported in any way. THANKS! I would think there are plenty of other people in my shoes...???

Marking beta2. The console is a badly-needed tool for content and web application developers who want to and are trying hard to support us. Alas this won't make beta1, but we'll be sure to get it in for beta2.

cc'ing mccabe on this as he's shown me a prototype.

Prototype is landed in the tree. tasks->tools->JavaScript Console. javascript: still doesn't bring it up, though :)

On a build from the tip at 2am 04/05 I can open the javascript console, but no JS exceptions are displayed. Also, I am not sure how errors in chrome JS are going to be displayed, as there is no way to bring up this dialog if there are parse errors in the chrome JS code. This is a major blocker for chrome development for me just now.

I know mccabe is looking into why errors are not always getting to the console. If chome is horked then errors still get printf'd (at least in debug builds) at this point. Do you have a better alternative? You could hack the code to write these errors to a file given a certain prefs setting. I doubt many people not hacking the chrome would have use for such a feature though.

Somehow, I managed to get everything tested and working with XUL javascript referring to outdated progids for the console service. I think I just saw dynamic linking and CIDs in action. Changing 'consoleservice' to 'mozilla.consoleservice.1' fixes it. Thanks for the catch. So far as I know, the console service should also catch errors in UI js, at least those that don't prevent the console itself from coming up. As John pointed out, you can also currently see them on stdout for now. A pref-enabled error log file is also a good idea.

Indeed, on my latest build syntax errors show up on the console. I added a menu option to my chrome opening up the JS console, so I get to see the runtime exceptions as well. Maybe a command line option could be added to bring it up when starting moz: ./mozilla -jsconsole -chrome chrome://zopestudio/content So's I can bring it up on any chrome in development. Up next: hacking the JS console to open up my editor on the offending line when doubleclicking on the error... ;)

mj - both these ideas sound great. A console command line option would be useful - could you look at contributing code for one? I'd be happy to check it in. I've been thinking about poking around in the viewsource: url to see about bringing up a window with the appropriate line highlighted. Have you looked at that?

That should teach me to make jokes =) I have, however, no experience with C++ except what I have from textbooks, and sspitzer hasn't documented how you can create command line handlers from JS. What documentation there is can be found here: http://www.deja.com/getdoc.xp?AN=594590293 Now, having glanced over the -editor implentation of this, it should be pretty straightforward by creating a nsJSConsoleService set of files, where nsJSConsoleService.cpp contains the line: CMDLINEHANDLER_IMPL(nsJSConsoleService,"-jsconsole","general.startup.jsconsole","chrome://global/content/console.xul","Start with javascript console .","component://netscape/commandlinehandler/general-startup-jsconsole","JS Console Startup Handler", PR_FALSE,"about:", PR_FALSE) Again, this is all from my limited understanding of the workings here. nsJSConsoleService has to be registered somewhere (nsEditorService is registered at editor/base/nsEditorRegistration.cpp line 69, for example). There needs to be a nsJSConsoleService.h and .idl, and all these files have to be hoked into Makefiles somewhere. *shudder* I'll surely break something. As for bringing up a viewsource window, I can't see any way of telling the viewsource window what line to highlight. This is something I don't really have time to implement anyway, so I'll keep to my statement I only made a joke about this.

Ben, could you provide more info on whether this is indeed a beta2 stopper? -- pdt

While writing a commandline handler for -zopestudio, I made one for -jsconsole as well. Save as jsconsole-service.js in the components/ subdirectory, kill the component.reg file and fire up mozilla to register it. A few caveats: - It doesn't actually work, yet. =/ It should, but I think the command line handler manager needs some work or something. - './mozilla -help' doesn't show -jsconsole until you start up ./mozilla without arguments, because only then does Mozzie autoregister. After this './mozilla -help' will list the option like it should. - './mozilla -jsconsole' doesn't fire up the javascript console. No idea why not, and I don't have the resources to find out why. The code is based on the commandline handler for '-chat' that was recently checked in, and as far as I can see and debug, that one sholdn't work either... I added sspitzer to the CC list for these reasons, maybe he'd be willing to have a peek, and offer an explanation.

wow, it's cool to see people using the command line handling stuff. especially since there is no documentation, except for the C++ code, and the chatzilla-service.js the problem with jsconsole-service.js is that your PROGID is incorrect. your's is: const JSCONSOLESERVICE_PROGID = 'mozilla.jsconsole-startup.1'; it needs to be: const JSCONSOLESERVICE_PROGID = "component://netscape/commandlinehandler/general -startup-jsconsole"; I just tried that, and now -jsconsole works. there is a reason why your progid has to be that way. I've started a document at http://www.mozilla.org/docs/command-line-args.html and I'll add the reason why your progid has to be that way to that document (plus a link to chatzilla-service.js and jsconsole-service.js, once you check it in.) I'll also add information about why you have to run mozilla once, before -help works. nice to see someone using the command line handling code!

Seth, This is whacky. http://bugzilla.mozilla.org/show_bug.cgi?id=37275

jband, see my comment 37275 about why this isn't that whacky.

On another note... I vote that there is no real need to support the old behavior that typing "javascript:" in the location bar would bring up the console. That was always just a hack. It was ugly. We don't need it. I *do* think that we need a visible small icon in the corner of the status bar. Clicking on it will always bring up the console. On pages where JS errors have occured the icon image will change in some interesting way to indicate the error. Most people won't care. Those that do care will have a few pixels on the screen that will clue them in. This would be patterned after the security padlock.

Regardless of what individual people may think about the aesthetics of typing "javascript:" to bring up the error console, that's how 4.x has worked for a while, so it's how developers will expect Mozilla/N6 to work. Developers have been specifically asking for a working JS console ASAP to help them upgrade to N6, and we'd like to get that enabled and easily findable ASAP rather than (by not enabling javascript: access) causing them to think it doesn't exist. We could debate back and forth whether "javascript:" is ugly or beautiful or a hack, but I think that even if we all were to agree that it is an ugly hack, in this case backward compatibility with developer expectations is more important. Moreover, if they type javascript: in Moz/N6 and don't get a console, they'll file bugs and we'll have to deal with those. Additional point: changing the status bar would be a UI modification, and we'd have to take that to the folks who control the UI, and it's very late to be proposing new modifications. Even if that were unanimously agreed to be a better idea, there's no one with the time to push this proposal through. Bottom line: once we get the console working, having "javascript:" launch it shouldn't be much more work, so let's just enable that for backward compatibility, close this bug, and move on to other things.

Based on comments to 37275, I have updated my implementation of the command-line handler. It still will not work in current builds, but it does The Right Thing with regards to ProgID format and categorymanager usage. I had just copied over the categorymanager code without paying much attention. I have now changed that code to follow the CategoryManager IDL. You can now ask the catagory manager for the 'jsconsole' entry of the 'command-line-argument-handlers' category, which will return the 'org.mozilla.general-startup.jsconsole.1' ProgID. To find out that there _is_ a jsconsole entry in that category, ask the manager for all entries in the category. One more point for sspitzer on command-line arguments: When I (using a working version of this component) use './mozilla -jsconsole' _only_ the jsconsole will start, no browser. Is there any way we can indicate that this command line flag is for a 'secondary window'? It should start up together with a primary window, which is the browser if no other flags have been given. This also brings me to another Q: how can I specify command-line arguments that don't bring up a window, but are nothing but a modifier for a primary or secondary chrome. Something like -noproxy or something. Hmm.. this is beginning to get way offtopic. New bug time. Bugs #37368, #37369 and #37370.

Cool! Where should the new file live? Also, could you provide diffs for other files to tie this in? Also, I notice the new file is implemented as a JavaScript component. It's just being called from C++, right? The reason I ask is that JavaScript components currently *don't* present themselves as XPCOM components to other JavaScript, instead showing up as plain JavaScript objects - and encouraging access to them in ways that violate the interface. This puts us in danger of compatibility when we put a better XPCOM layer on top of them. If you're just calling the object from C++, no problem. FWIW, the need for startup with console-and-browser may be alleviated somewhat when I get off my butt and add the standard task bar (with a 'browser' button) to the JS console.

Putting on [nsbeta+] radar.

I know of the JS -> JS component pitfalls, believe me =). This component only gets called from C++, and there isn't anything to work around in it anyway. Place it in the components subdirectory, an autoreg will find it and register it. Sorry, no diffs to tie it in. All the Makefile has to do is make sure the file gets placed in the components directory. That's it. The rest is XPCOM magic.

Ah, I see. xpfe/components/console?

That looks like the best place. Don't forget that only the first version I submitted, with sspitzers modification of the ProgID (which is defined on the first line of the code) will work in current builds. If and when sspitzer fixes bug #37370, the second version should work.

I still need to read all the comments here, but before I go to sleep, did you make the necessary changes to export this .js file to right place on all three platforms? if not, I can help. (I had to do it for chatzilla-service.js)

I haven't. I think I have a handle on what to do to land it, but please feel free; I didn't follow every aspect of the progid discussion, and it seems like that changes just what I need to land.

-jsconsole handler checked in. Thanks! I changed several uses of 'Service' to 'Handler' in the code, because jsConsoleService sounded too close to nsConsoleService (also in the tree) and they're pretty different. I export the component for unix and windows. Is it relevant on the mac?

yes, please export that *.js file to the right place on the mac.

Exported.

mccabe, if you are feeling really adventurous, you could add the special file "Mozilla JS Console" to the build. that requires two things see how we do it for "Mozilla Messenger" http://lxr.mozilla.org/seamonkey/source/build/mac/NGLayoutBuildList.pm#1987 http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/Mozilla_Messenger if you need help, let me know.

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

Bug 6211 is about displaying errors in a document's HTML, CSS, HTTP, etc, not just in JS, and displaying general status (valid/invalid document) in the browser UI. This bug, on the other hand, looks like it is just for JavaScript errors. Can someone confirm whether the JavaScript console is or isn't going to show errors with those other languages? If so, why is it called the `JavaScript console'? And if not, I'll un-dup 6211.

The JS console is a good place for any persistent user-visible feedback that we don't want to pop up an alert for. CSS, XML, etc. Do we ever show users errors for HTML?

Great work on getting the JavaScript console hooked up, and thanks for everyone's teamwork and enthusiasm! That said, it's important to remember some things w.r.t. the proposal to expand the JS Console's functionality to cover other kinds of errors: 1) Our only goal for FCS is to have functional parity with the JS Console of 4.x. 2) Adding more beyond that is an enh request, and we're cutting all of those off at this point in the interest of shipping. Please file a separate enh request bug to add other kinds of errors to the JS Console and mark it FUTURE if you wish. 3) The JS Console may not be the best, most logical place for all kinds of errors. Documenting markup errors there could be difficult to understand (hard to figure out where in a 120k page the markup is) and might make it harder to find JS errors within all the markup warnings, thus impeding our JS developers who are the primary targets of this feature. The View Source window would be a great place to show HTML and CSS errors. In fact, Rick has already been experimenting with this; not sure how much is in. We *DEFINITELY* don't want to be duplicating each other's work. We would need to do design work, reviews, and coordination on the best way to present each kind of error--none of which we have time for now. 6211 has been un-duped and (appropriately) marked FUTURE.

Here's what I intend to do to resolve this bug: 1) provide support in navigator (via javascript) for 'javascript:' to launch the JS console 2) provide an icon on the statusbar next to the text area describing the load status of the document. [||||| ] [*] [ 248 bytes read ] The icon normally shows a standard document, but will change to give some visual feedback of an error (and a tooltip - 'An error has occurred on this page. Double click for details.') In future versions this icon can be enhanced as desired. Time to complete: 1 day.

Ben, I'm glad you're looking at this! >2) provide an icon on the statusbar next to the text area describing the load > status of the document. > [||||| ] [*] [ 248 bytes read ] You can probably do this by setting a listener with the console service.

Move to M19.

Putting on [nsbeta2-] radar, removing [5/16][FEATURE]. Did not make it for netscape 6.

Ben, a status icon in the bottom left of the window is one of the likely implementations for bug 6211, reporting HTML errors (see the bottom left corner of <http://critique.net.nz/project/mozilla/navigator/navigator.jpg>). I'm not sure using such an icon for JS errors too is such a good idea. Reporting JavaScript problems caused by a JavaScript version more recent than this version of Mozilla is not a problem with the page itself, but is still important enough to be reported, so it would get the `error' icon; but reporting errors caused by an HTML version more recent than this version of Mozilla would be breaking faith with those authors who were writing standards-compliant pages. So the approach to error-reporting would be inconsistent between HTML and JS, but they'd be (presumably) using the same icon. Better for JavaScript errors, I think, would be to show an error dialog like IE does, but give the option of opening the console from the dialog. `An error has occurred in a script running on this page. Do you want to continue running this script? [View Errors] [Stop] [Continue]'

On the last point (showing a dialog) - we've been down that road before with early versions of 4.x. Most (nearly all) viewers of a page are not the authors of the page, and don't want to see an alert pop up in their face. There's a reason we did away with popup JavaScript errors. Better to put it on the console, possibly with some unobtrusive indication on the page that an error has occured.

If an application on my OS falls over, I expect a dialog from my OS which tells me what happened and (roughly, at least) why it happened. This applies whether or not I happen to be the author of the app (usually, of course, I'm not). And if a JavaScript-using app on a Web page falls over, I expect exactly the same thing -- a dialog from my browser which tells me what happened and (roughly, at least) why it happened. This applies whether or not I happen to be the author of the page (usually, of course, I'm not). The only difference here is that with JavaScript, unlike a compiled executable, we have a fair chance of being able to continue after a transitory error -- so we can give the user the option of continuing or not continuing. This is what IE does, and it's very handy on sites (like Hotmail) which contain screeds of JavaScript with a very occasional bug. If a page gets completely sozzled by faulty JavaScript, I'm not going to notice a small change in the status bar; my mind is going to be on other things (like, what the smeg's this page doing?). I need more obvious feedback than a status bar change. If you really want, have a checked-by-default `Warn me about future errors on this page' checkbox on the dialog (the checkbox would apply only until the user navigated to a different page).

Personally, I agree with both of you. I also think that there are many people that see it from BOTH of your viewpoints. Some people want to see the pop-ups, others don't, regardless of whether or not they are the author. Nice people like me like to see the errors because then we'll write the page author to let them know about it so they can fix it. Therefore, I suggest there be some sort of checkbox that has a more general question than mentioned above. Possibly something like "Warn me about future javascript errors," applying to any page rather than just this page. Also having this option adjustable via preferences would be important. Correct me if I'm wrong, but I believe this is an option in IE as well. Hope these third party comments are of use...

IIRC (although my memory is hazy), the first time you receive a js error in IE you get a dialog. It is a checkbox dialog that defaults to never showing the alert dialogs again. Since we have no current plan to show the dialogs (although this would make a good RFE for a pref for those that wanted to see them, like IE's pref) I still believe a clickable status message is a worthy supplement to 'javascript:', which is the geekiest of them all. Matthew, if you feel strongly for the dialogs please file an RFE asking for user friendly msgs in response to page errors (cf error console).

This bug needs to be for just the 'javascript:' implementation period. All other issues need to be split out into RFE's or whatever's appropriate. nav-triage says this is a plus for the javascript: only. I believe it to be fixed on Win98 with the 2000072108 build by the way.

Logged 46277 for matthew's issue about user friendly messages on errors in javascript.

nav triage team: [b3nav+] now = [nsbeta3+]

This works now. I think Brendan fixed it.

I've filed bug 47128 regarding showing a JavaScript error message indicator in the statusbar.

Adding keyword to bugs with nsbeta3 triage value in status whiteboard so tracking queries will not be misled

Verified with 2000-09-13-09.

This bug was reborn as bug 59748.