Closed Bug 4263 Opened 24 years ago Closed 22 years ago
2.58 KB, text/plain
2.54 KB, patch
|Details | Diff | Splinter Review|
Assignee: don → jband
you'all gona make it for M4? Or should I Release Note. I need an 'M' here please?
Moved to M5.
Brendan, do you want to take this one as well?
Sure, thanks. /be
Status: NEW → ASSIGNED
OS: Windows NT → All
Target Milestone: M6 → M8
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
Assignee: brendan → ben
Status: ASSIGNED → NEW
not for m14. need to discuss further w/brendan.
Status: NEW → ASSIGNED
Target Milestone: M14 → M15
23 years ago
Target Milestone: M15 → M16
*** Bug 28047 has been marked as a duplicate of this bug. ***
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.
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.
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?
Ben, could you provide more info on whether this is indeed a beta2 stopper? -- pdt
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.
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.
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.
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. ***
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?
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-]
Whiteboard: [nsbeta2-] → [nsbeta2-][b3nav+]
nav triage team: [b3nav+] now = [nsbeta3+]
Whiteboard: [nsbeta2-][b3nav+] → [nsbeta2-][nsbeta3+]
This works now. I think Brendan fixed it.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Adding keyword to bugs with nsbeta3 triage value in status whiteboard so tracking queries will not be misled
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.