Closed Bug 4263 Opened 25 years ago Closed 24 years ago

no JS console after javascript: error and typing in Location bar

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ekrock, Assigned: bugs)

References

(
URL
)

Details

(Whiteboard: [nsbeta2-][nsbeta3+])

Attachments

(2 files)

Proposed commandline handler, jsconsole-service.js
2.58 KB, text/plain
Details
New command line argument handler component, jsconsole-service.js
2.54 KB, patch
Details | Diff | Splinter Review 
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
Assignee: don → jband
Component: Apprunner → JavaScript Debugger
Priority: P1
Re-assigned to jband@netscape.com and changed component to JavaScript Debugger.
Assignee: jband → joki
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).
Assignee: joki → vidur
javascript: in general is busted right now.  That could be part of this.
javascript:'s are Vidur's land.
QA Contact: 3853 → 4078
you'all gona make it for M4? Or should I Release Note.  I need an 'M' here
please?
Status: NEW → ASSIGNED
Target Milestone: M5
Moved to M5.
Target Milestone: M5 → M6
Waiting for the new netlib before I rewrite javascript: URL processing.
Assignee: vidur → brendan
Status: ASSIGNED → NEW
Brendan, do you want to take this one as well?
Sure, thanks.

/be
Status: NEW → ASSIGNED
Component: JavaScript Debugger → JavaScript
OS: Windows NT → All
Target Milestone: M6 → M8
Component: JavaScript → Javascript Engine
Moving to Javascript Engine component.  Javacript component being retired.
Component: Javascript Engine → Networking Library
I'm putting this in the netlib component, an imperfect fit, but closest.

/be
Target Milestone: M8 → M9
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. ;-)
Target Milestone: M9 → M10
This can wait till M10.

/be
Blocks: 12182
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.
Summary: javascript: typed in location bar after error doesn't display JS console → no JS console after javascript: error and typing in Location bar
Target Milestone: M10 → M11
Target Milestone: M11 → M12
Ben's gonna help out with the console design and XUL.

/be
Target Milestone: M12 → M13
M13 so we can do it when Ben gets in country.

/be
QA Contact: phillip → desale
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
Priority: P1 → P3
Target Milestone: M13 → M14
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
Assignee: brendan → ben
Status: ASSIGNED → NEW
not for m14. need to discuss further w/brendan.
Status: NEW → ASSIGNED
Target Milestone: M14 → M15
Target Milestone: M15 → M16
*** 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.
Keywords: 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.
Keywords: nsbeta2
Ben, could you provide more info on whether this is indeed a beta2 stopper? -- 
pdt
Keywords: beta2
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!
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.
Keywords: 4xp
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.
Whiteboard: [nsbeta2+][5/16][FEATURE]
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.
Target Milestone: M16 → M19
Putting on [nsbeta2-] radar, removing [5/16][FEATURE].  Did not make it for 
netscape 6.
Whiteboard: [nsbeta2+][5/16][FEATURE] → [nsbeta2-]
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.
Whiteboard: [nsbeta2-] → [nsbeta2-][b3nav+]
Logged 46277 for matthew's issue about user friendly messages on errors in 
javascript.
nav triage team: [b3nav+] now = [nsbeta3+]
Whiteboard: [nsbeta2-][b3nav+] → [nsbeta2-][nsbeta3+]
This works now. I think Brendan fixed it.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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
Keywords: nsbeta3
Verified with 2000-09-13-09.
Status: RESOLVED → VERIFIED
This bug was reborn as bug 59748.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: