"javascript:" does not open javascript console window

VERIFIED FIXED in mozilla0.9.2

Status

()

Core
Security
P3
normal
VERIFIED FIXED
17 years ago
6 years ago

People

(Reporter: Vladimir Ermakov, Assigned: Dan M)

Tracking

({regression, relnote})

Trunk
mozilla0.9.2
x86
All
regression, relnote
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: wanted for 0.9)

Attachments

(5 attachments)

(Reporter)

Description

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

Comment 1

17 years ago
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.
Assignee: jband → mccabe
(Reporter)

Comment 2

17 years ago
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!

/be

Comment 4

17 years ago
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?
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
(Reporter)

Comment 6

17 years ago
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

Comment 7

17 years ago
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

17 years ago
Nominated for rtm.
Keywords: rtm

Comment 9

17 years ago
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-]
(Reporter)

Comment 10

17 years ago
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

17 years ago
Vlad, there is no time to fix it; we'll add it to the release notes.
Keywords: relnote
(Reporter)

Comment 12

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

Comment 13

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

Comment 14

17 years ago
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

17 years ago
*** 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?

/be

Comment 17

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

/be

Comment 19

17 years ago
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.)
(Reporter)

Comment 20

17 years ago
"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
(Reporter)

Updated

17 years ago
Keywords: nsbeta1

Comment 21

17 years ago
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

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

Updated

17 years ago
Keywords: regression

Comment 23

17 years ago
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

Comment 24

17 years ago
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

Comment 25

17 years ago
reassign to rginda
Assignee: jband → rginda

Comment 26

17 years ago
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);
     }
Status: NEW → ASSIGNED
(Assignee)

Comment 27

17 years ago
  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
Status: ASSIGNED → NEW
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?
Status: NEW → ASSIGNED

Comment 30

17 years ago
Add "dialog=no" to the OpenDialog flags?
that did it. gracias.

Comment 32

17 years ago
a= asa@mozilla.org (on behalf od drivers) for checkin to 0.9
Whiteboard: [rtm-] → [rtm-] wanted for 0.9
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 17 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/
components/jsconsole/nsJSConsoleService.cpp.

according to danm, this shouldn't have been fixed the way it was.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9 → ---
over to dan to see what to do.
Assignee: pinkerton → danm
Status: REOPENED → NEW
Whiteboard: [rtm-] wanted for 0.9 → wanted for 0.9
(Assignee)

Comment 36

17 years ago
  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

17 years ago
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.
That's mine. Looking at it.

The JS console is NOT the JS debugger.
Assignee: danm → mstoltz
Component: JavaScript Debugger → Security: General

Comment 39

17 years ago
I'll look at this for 0.9.2.
Assignee: mstoltz → jesse
Severity: critical → normal
Target Milestone: --- → mozilla0.9.2
(Assignee)

Comment 40

17 years ago
talked with Jesse, and taking the bug. rpotts and i have a plan.
Assignee: jesse → danm
(Assignee)

Comment 41

17 years ago
Created attachment 38769 [details] [diff] [review]
move URI security check out of windowwatcher, into the DOM
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.
(Assignee)

Comment 43

17 years ago
Created attachment 38958 [details] [diff] [review]
above patch but incorporating Johnny's comments
(Assignee)

Comment 44

17 years ago
Created attachment 39007 [details] [diff] [review]
one more time. like above but also fixes use of incorrect base URI.
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
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.
(Assignee)

Comment 47

17 years ago
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.
(Assignee)

Comment 48

17 years ago
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.
Status: NEW → ASSIGNED
(Assignee)

Comment 49

17 years ago
Created attachment 39209 [details] [diff] [review]
yet again. also fixes most base JS context problems while opening windows.
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

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

Comment 52

17 years ago
Created attachment 39245 [details]
rs=hyatt

Comment 53

17 years ago
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
(Assignee)

Comment 54

17 years ago
.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 55

17 years ago
Verifying fixed on build 2001-06-21-04
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.