59748 - "javascript:" does not open javascript console window

Status: VERIFIED FIXED

(Core :: Security, defect, P3)

Description

[Vladimir Ermakov]

Typing javascript: in the location doesnt start the javascript debugger. It just 
loads a blank page, as if trying to execute "" command.

Comment 1

[John Bandhauer]

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.

Thanks.

Comment 2

[Vladimir Ermakov]

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.

Comment 3

[Brendan Eich [:brendan]]

I made the console magic work -- don't tell me someone regressed it!

/be

Comment 4

[John Bandhauer]

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 
'cnn.com') 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?

Comment 5

[Brendan Eich [:brendan]]

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!".

/be

Comment 6

[Vladimir Ermakov]

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.

Comment 7

[gerardok]

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.

Comment 8

[gerardok]

Nominated for rtm.

Comment 9

[selmer (gone)]

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-.

Comment 10

[Vladimir Ermakov]

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. 

Comment 11

[gerardok]

Vlad, there is no time to fix it; we'll add it to the release notes.

Comment 12

[Vladimir Ermakov]

I checked the workabout on all platforms on latest MN6 builds and found no 
problems.

Comment 13

[John Bandhauer]

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

Comment 14

[Scott Brodmerkle]

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.

Comment 15

[Phil Schwartau]

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

Comment 16

[Brendan Eich [:brendan]]

Whose bug is this, anyway?  Works in classic, not in modern => modern skin owner?

/be

Comment 17

[djoham]

cc'ing self. Sorry for the spam

Comment 18

[Brendan Eich [:brendan]]

mccabe, ben: any chance of you guys mind-melding in front of a debugger?

/be

Comment 19

[Tim Powell]

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.)

Comment 20

[Vladimir Ermakov]

"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

Comment 21

[Mark Slater]

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 =)

Comment 22

[Jesse Ruderman]

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

Comment 23

[David Hallowell]

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.

Comment 24

[Phil Schwartau]

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 - 

Comment 25

[John Bandhauer]

reassign to rginda

Comment 26

[Robert Ginda]

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 window.open()
doesn't work for chrome:// urls. see bug 69546.

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

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 @@
                                        console_window_options);
         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);
     }

Comment 27

[Dan M]

  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.

Comment 28

[Mike Pinkerton (not reading bugmail)]

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.

Comment 29

[Mike Pinkerton (not reading bugmail)]

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?

Comment 30

[Simon Fraser [no longer active]]

Add "dialog=no" to the OpenDialog flags?

Comment 31

[Mike Pinkerton (not reading bugmail)]

that did it. gracias.

Comment 32

[Asa Dotzler [:asa]]

a= [e-mail] (on behalf od drivers) for checkin to 0.9

Comment 33

[Mike Pinkerton (not reading bugmail)]

fixed

Comment 34

[Mike Pinkerton (not reading bugmail)]

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/
components/jsconsole/nsJSConsoleService.cpp.

according to danm, this shouldn't have been fixed the way it was.

Comment 35

[Mike Pinkerton (not reading bugmail)]

over to dan to see what to do.

Comment 36

[Dan M]

  Welcome mstoltz to the conversation.
  This problem was once fixed by replacing a window.open 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 
URLs.
  javascript URLs would suddenly work if we instead used about:blank's parent, 
which is chrome. Heh. Thoughts, Mitchell?

Comment 37

[Jacob Huck]

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.

Error: 

This worked well on the 9.0 release.

Comment 38

[Mitchell Stoltz (not reading bugmail)]

That's mine. Looking at it.

The JS console is NOT the JS debugger.

Comment 39

[Jesse Ruderman]

I'll look at this for 0.9.2.

Comment 40

[Dan M]

talked with Jesse, and taking the bug. rpotts and i have a plan.

Comment 41

[Dan M]

Attachment: move URI security check out of windowwatcher, into the DOM

Comment 42

[Johnny Stenback (:jst)]

How about changing:

@@ -3015,7 +3015,7 @@
   nsresult rv;
 
   *aReturn = nsnull;
-  rv = NS_ERROR_FAILURE;
+  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.

Comment 43

[Dan M]

Attachment: above patch but incorporating Johnny's comments

Comment 44

[Dan M]

Attachment: one more time. like above but also fixes use of incorrect base URI.

Comment 45

[Johnny Stenback (:jst)]

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);
   nsMemory::Free(url);
   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 =
"@mozilla.org/embedcomp/window-watcher;1";
+static const char *sJSStackContractID="@mozilla.org/js/xpc/ContextStack;1";

Be consistent with spaces around '=' :-)

sr=jst

Comment 46

[Johnny Stenback (:jst)]

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.

Comment 47

[Dan M]

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.

Comment 48

[Dan M]

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.

Comment 49

[Dan M]

Attachment: yet again. also fixes most base JS context problems while opening windows.

Comment 50

[Johnny Stenback (:jst)]

In nsWindowWatcher.cpp I'd suggest changing:

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

to:

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

Oh, and nit of the day ;-) :

+nsWindowWatcher::GetJSContextFromCallStack()
 {
-  JSContext *cx;
+  JSContext *cx= 0;

Add a space before the '=' :-)

sr=jst, this is looking very good now.

Comment 51

[David Hyatt]

Johnny's review is good enough for r=, and sr=hyatta

Comment 52

[David Hyatt]

Attachment: rs=hyatt

Comment 53

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 54

[Dan M]

.

Comment 55

[Vladimir Ermakov]

Verifying fixed on build 2001-06-21-04