Closed Bug 59748 Opened 21 years ago Closed 21 years ago

"javascript:" does not open javascript console window


(Core :: Security, defect, P3)






(Reporter: vladimire, Assigned: danm.moz)



(Keywords: regression, relnote, Whiteboard: wanted for 0.9)


(5 files)

Typing javascript: in the location doesnt start the javascript debugger. It just 
loads a blank page, as if trying to execute "" command.
If you want to see the JavaScript console in NS6 (You *are* talking about NS6, 
right?) Choose from the menu: "Tasks::Tools::JavaScript Console". This is not 
the JavaScript Debugger. There is no JavaScript Debugger for NS6.

I thought someone hacked 'javascript:' in the taskbar to bring up the console. 
It doesn't work for me. mccabe, If this is supposed to work then please look 
into it. Else, please mark this invalid or something.

Assignee: jband → mccabe
This worked on 11/6 build. 
After putting "javascript:" in URL you can bring up the console from the menu 
and see an error with no location no information about it generated.
I made the console magic work -- don't tell me someone regressed it!

On NT with both branch and trunk I see: 

If I startup the browser and type in javascript: then the console shows. If I 
close the console and do it again it shows again. If I then type in a url (say 
'') then I get the blank window as reported and no js console. I also 
note that if I then close all mozilla windows the mozilla process does not exit 
and it is necessary to kill the process in the task manager.

Who shall we bring in to help? danm?
Bringing in experts, but I predict that someone will have to dig into the
particulars with a debugger and report back before anyone else says "aha!".

Changing the name to better suit the bug. I am also seeing the problem John 
reported where I have to use task manager/end task to close netscape6.
Summary: JavaScript debugger doesnt Work! → "javascript:" does not open javascript console window
This must have started happening after Mondays checkins in the branch. I've 
checked 2000-11-06-09-MN6 build and the javascript console launches fine.
Nominated for rtm.
Keywords: rtm
11/8 MN6

On win98, tends to hang as described (and also when ctrl-W is used to close
windows.)  If you use File | Exit, or ctrl-Q from ANY open window, then netscp6
exits normally.

Since non-developer users would never do this, I'm marking this rtm-.
Whiteboard: [rtm-]
There is a LOT of developers out there who use it though. I cant imagine writing 
a script without using the console. This bug should definately be fixed as soon 
as possible. It will have huge impact on developer's world. 
Vlad, there is no time to fix it; we'll add it to the release notes.
Keywords: relnote
I checked the workabout on all platforms on latest MN6 builds and found no 
*** Bug 60198 has been marked as a duplicate of this bug. ***
In duplicate bug 60198, the reporter indicated that "javascript:" opened the
console window with the Classic skin but not Modern, on the Nov. 14th Win98
build. Using the same build, I observed identical behavior on Linux.
*** Bug 60536 has been marked as a duplicate of this bug. ***
Whose bug is this, anyway?  Works in classic, not in modern => modern skin owner?

cc'ing self. Sorry for the spam
mccabe, ben: any chance of you guys mind-melding in front of a debugger?

It does not work for me with Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18)
Gecko/20001214 and the Classic skin. I get the same blank page as if it executed
javascript:"". Adding this because it isn't clear to me whether Brendan Eich's
12/04 comment means that it was working 12/04 in the classic theme or just that
it was working back in Nov.

Sometimes I wonder if it doesn't work for me just because of the overly
aggressive autocompletion (I type a lot of javascript: urls for debugging purposes.)
"javascript:" starts working after applying a theme. It doesnt matter what theme 
you apply, even if its the same theme you currently have, but after quitting and 
starting the browser again the problem returns. 

Tested on Linux 2000-11-16-Mtrunk, Windows 2000-11-16-MN6,
 and Mac 2000-11-10-MN6
Keywords: nsbeta1
Y'know, purely from a developer perspective, having a bookmark with URL
"Javascript:" is an absolute god-send. If only it would work... please please
fix this =)
*** Bug 68785 has been marked as a duplicate of this bug. ***
Keywords: regression
Nominating for mozilla 0.9 and adding the 4xp keyword as this feature was in
communicator. We need some quick way of accessing the console without navigating
the menus and I don't think it'll be used by enough people to warrant a keyboard
shortcut so a bookmarkable javascript: url that can be placed in the personal
toolbar will please many developers as a quick way of accessing the console.
Keywords: 4xp, mozilla0.9
Mass-reassigning mccabe's non-JS, non-Rhino bugs to jband (34 total). 

Would like to cc mccabe; but the mass-reassign page does not allow this. 
I'll leave it up to mccabe to decide if he wants to be cc'ed on these - 
Assignee: mike+mozilla → jband
reassign to rginda
Assignee: jband → rginda
I think there's a better way to open a xul window from C++ than resorting to
JS_PushArguments, but maybe there's is some security or script ownership issue
here that I don't know about.  Anyway, this patch fixes it on linux, and I
suspect everwhere else too.  The problem appears to be that
doesn't work for chrome:// urls. see bug 69546.

Could someone properly endowed please test this on mac/windows?  Then maybe an

Index: nsJSProtocolHandler.cpp
RCS file: /cvsroot/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp,v
retrieving revision 1.55
diff -u -r1.55 nsJSProtocolHandler.cpp
--- nsJSProtocolHandler.cpp     2000/09/13 23:50:39     1.55
+++ nsJSProtocolHandler.cpp     2001/04/17 01:37:05
@@ -225,7 +225,7 @@
         if (!argv) return NS_ERROR_OUT_OF_MEMORY;
-        rv = window->Open(cx, argv, 3, getter_AddRefs(console));
+        rv = window->OpenDialog(cx, argv, 3, getter_AddRefs(console));
         JS_PopArguments(cx, mark);
  Oh boy. I just noticed this one. Yes, it's the security manager that prevents 
opening a javascript: URL from content. OpenDialog gets special dispensation from 
the security manager; that's probably why your patch works.
  Here I'd been thinking this was intentional. Reinstating the JS console affects 
the embedding API. See bug 73127. See comments I put there just today.
yes, this patch allows the console to show up on mac. r=pink, we have permission 
from drivers to land. i'll do that soon.
Assignee: rginda → pinkerton
Target Milestone: --- → mozilla0.9
the problem with this patch is that now we think this is a dialog, so the mac 
doesn't get a closebox. smfr, any thoughts?
Add "dialog=no" to the OpenDialog flags?
that did it. gracias.
a= (on behalf od drivers) for checkin to 0.9
Whiteboard: [rtm-] → [rtm-] wanted for 0.9
Closed: 21 years ago
Resolution: --- → FIXED
reopening. the latest way we're doing this, with the window watcher, yields the 
same security errors as before. the code to open the window is now in embedding/

according to danm, this shouldn't have been fixed the way it was.
Resolution: FIXED → ---
Target Milestone: mozilla0.9 → ---
over to dan to see what to do.
Assignee: pinkerton → danm
Whiteboard: [rtm-] wanted for 0.9 → wanted for 0.9
  Welcome mstoltz to the conversation.
  This problem was once fixed by replacing a with a 
window.openDialog, which has an innate immunity to security system surveillance. 
But that trick doesn't really work any more.
  The console window fails to open because it fails a security check. The DOM 
Window from which URLbar URL loads are spun looks like the browser content 
window. Which makes sense. At any rate it's something with a codebase principal 
URI of "about:blank". Such windows are disallowed from opening javascript scheme 
  javascript URLs would suddenly work if we instead used about:blank's parent, 
which is chrome. Heh. Thoughts, Mitchell?
With Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010607 I am
seeing the exact description posted From John Bandhauer on 2000-11-10 13:54.  If
I open it using Tasks | Tools | Javascript Console, I see the following:

The link to chrome://global/content/console.xul was blocked by the security manager.
Remote content may not link to local content.


This worked well on the 9.0 release.
That's mine. Looking at it.

The JS console is NOT the JS debugger.
Assignee: danm → mstoltz
Component: JavaScript Debugger → Security: General
I'll look at this for 0.9.2.
Assignee: mstoltz → jesse
Severity: critical → normal
Target Milestone: --- → mozilla0.9.2
talked with Jesse, and taking the bug. rpotts and i have a plan.
Assignee: jesse → danm
How about changing:

@@ -3015,7 +3015,7 @@
   nsresult rv;
   *aReturn = nsnull;
+  rv = NS_OK;
to initialze rv where it's declared?

In GlobalWindowImpl::SecurityCheckURL(), shouldn't cx come from the caller and
not from the window on wihch .open() is called? I.e.

+  cx = (JSContext *)mContext->GetNativeContext();

needs to come off the context stack.

And also:

+  nsJSUtils::GetStaticScriptContext(cx, mJSObject,
+                                    getter_AddRefs(scriptCX));

will get you mContext so you might as well just use that.

The other changes look good to me.
Looks good, good that you fixed the problem with us using the wrong base URI
too. A few minor comments:

At the end of GlobalWindowImpl::OpenInternal():

+  if (features)
+    nsCRT::free(features);
+  if (name)
+    nsCRT::free(name);
   return rv;

You should use nsMemory::Free() in stead of nsCRT::free() for consistency with
the free we're already doing there if nothing else...

In GlobalWindowImpl::SecurityCheckURL():

Initialize 'cx' to nsnull in case stack->Peek(&cx) would fail for some reason.

Nitpick of the day:

+static const char *sWindowWatcherContractID =
+static const char *sJSStackContractID=";1";

Be consistent with spaces around '=' :-)

Actually, I just realized that nsWindowWatcher::GetExtantJSContext() is getting
the context from the parent before it looks at the context stack, that will make
us use the uri of the document in the parent window as the base (if there is a
parent) and not the one that we get from the context on the context stack.

I'm reverting my sr= for now until we figure out if that's correct or not.
Actually in the patch, in this case, GetExtantJSContext gets its context from the 
call stack, not the parent window. I've tested the patch; there's no problem with 
its usage of that method. The question is whether the other two uses of 
GetExtantJSContext would benefit from a reversal of order.
Taking another shot at it in the patch below. This patch I think fixes every 
problem here except that arguments attached to the newly opened window are 
(still) built in the parent window's context, rather than the new window's. My 
understanding is that this is not terrible, but if one of the arguments happens 
to be an XPCOM object, it will extend the lifetime of the parent window past 
when it might normally be garbage collected. That's a bit of trouble to fix.
In nsWindowWatcher.cpp I'd suggest changing:

+  if (cx) {
+    nsCOMPtr<nsIScriptContext> scriptcx = (nsIScriptContext *)
+    if (scriptcx) {


+  if (cx) {
+    nsISupport *cxp = (nsISupports *)JS_GetContextPrivate(cx);
+    nsCOMPtr<nsIScriptContext> scriptcx(do_QueryInterface(cxp);
+    if (scriptcx) {

Oh, and nit of the day ;-) :

-  JSContext *cx;
+  JSContext *cx= 0;

Add a space before the '=' :-)

sr=jst, this is looking very good now.
Johnny's review is good enough for r=, and sr=hyatta
Attached image rs=hyatt
a= for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Verifying fixed on build 2001-06-21-04
You need to log in before you can comment on or make changes to this bug.