38537 - javascript: URLs entered in urlbar (location bar) don't work

Status: VERIFIED DUPLICATE of bug 31818

(Core :: DOM: Core & HTML, defect, P3)

Description

[Masahiro Iwamoto]

Entering javascript:something in URL Editbox is ignored,

or even worse, crash.



I tried this with 2000.04.23 SeaMonkey checkout,

and 2000.05.02 SeaMonkey checkout. ( MileStone 16 ? )

And tried Debug-Build and Release-Build.



Mac OS J1.9.0.2, Power Macinsoth G4 .



I tried

  javascript:window.open( "http://www.mozilla.org" );

  javascript:window.alert( "abc" );

  javascript:history.back();

  javascript:window.location="http://www.mozilla.org";

  javascript:window.open(

     "chrome://global/content/about.xul","about","chrome" );

  .

  .

  .



The results are

  ignored, or Mac OS TYPE 12 EXCEPTION.

Comment 1

[Andreas Franke (gone)]

It would help if you could explicitly say which of the URLs are ignored,
and which cause a crash. E.g. javascript:history.back(); not working is 
bug 21373.
I tried PC/Linux build 2000050811 with the five javascript URLs mentioned 
here, and I always got something like this in the shell output:
	Error loading URL javascript:...
except with javascript:window.location="http://www.mozilla.org";
which causes mozilla to lock/freeze. I'm going to attach the stack trace 
here. This lockup may be a dup of bug 38168 and/or bug 37463. 

I don't know if it's possible on Mac to start mozilla from a shell
and monitor the output, but that might also help. The option `-console'
could also be useful (if it's supported on Mac).
There are quite a lot of open javascript bugs right now, see:

http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=javascript&short_desc_type=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time

Comment 2

[Andreas Franke (gone)]

Attachment: full stack trace, PC/Linux, build 2000042809, thread 2

Comment 3

[Andreas Franke (gone)]

Note that you have to switch to thread 2 after interrupting with Ctrl-C.
The stack there starts like this:
#0  __sigsuspend (set=0xbfffe2c8)
#1  __pthread_lock (lock=0x865a83c, self=0x401abe80) 
#2  __pthread_mutex_lock (mutex=0x865a82c)
#3  PR_Lock ()
#4  PR_EnterMonitor ()
#5  nsFileTransport::Cancel ()      from components/libnecko.so
#6  nsStreamIOChannel::Cancel ()    from components/libnecko.so
#7  nsLoadGroup::Cancel ()          from components/libnecko.so
#8  nsDocLoaderImpl::Stop ()        from components/liburiloader.so
#9  nsURILoader::Stop ()            from components/liburiloader.so
#10 nsDocShell::StopLoad ()         from libdocshell.so
#11 nsDocShell::StopCurrentLoads () from libdocshell.so

Comment 4

[Andreas Franke (gone)]

Actually the lockup is a dup of bug 37463 (same stack trace in thread 2).
So this bug now is only about the other testcases.

Comment 5

[Masahiro Iwamoto]

/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

As for javascript:window.alert("abc"),

JavaScript interpret fails,

causing "JavaScript error: line 0: "

to console.



As for javascript:history.back(),

no javascript error and javascript kicking

History normally.

So maybe History Object is responsible.



/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

for javascript:window.alert("abc");

I made stack trace.



[how to]

1. Kicking up AppRunner.

2. When main browser appears,

   enter "javascript:window.alert("abc");"

   in URL-editbox and hit return.



MozillaDebug 0x232534D0 (PPC)

main

main1(int,char**,nsISplashScreen*)

APPSHELL_DLL 0x2311E764 (PPC)

WIDGET_DLL 0x22FB38B4 (PPC)

WIDGET_DLL 0x22FB4164 (PPC)

WIDGET_DLL 0x22FB49BC (PPC)

NETLIB_DLL 0x2157EA28 (PPC)

WIDGET_DLL 0x22F8CED4 (PPC)

WIDGET_DLL 0x22F8D1B0 (PPC)

XPCOM_DLL 0x217132B8 (PPC)

XPCOM_DLL 0x21789300 (PPC)

XPCOM_DLL 0x21789444 (PPC)

XPCOM_DLL 0x21755C20 (PPC)

XPCOM_DLL 0x2174E0D4 (PPC)

XPCOM_DLL 0x2174E1DC (PPC)

JSUrl 0x2071E00C (PPC)

EvaluateString(const nsString&,void*,nsIPrincipal*,const char*,unsigned int,const 

char*,nsString&,int*)

JS_EvaluateUCScriptForPrincipals

js_Execute

js_Interpret

js_GetProperty





In the op-code interpret loop of "js_Interpret",

first comds "op = JSOP_NAME",

and then "op = JSOP_GETPROP".



In this JSOP_GETPROP process,



  case JSOP_GETPROP:

    /* Get an immediate atom naming the property. */

    atom = GET_ATOM(cx, script, pc);

    id   = (jsid)atom;

    PROPERTY_OP(CACHED_GET(OBJ_GET_PROPERTY(cx, obj, id, &rval)));

    PUSH_OPND(rval);

    break;



"PROPERTY_OP" macro calls "js_GetProperty",

and fails to get "ok = 0",

as a result, "JavaScript error: line 0: ".





In this "js_GetProperty" function,



JSBool

js_GetProperty(JSContext *cx, JSObject *obj, jsid id, jsval *vp)

{

        .

    if (!SPROP_GET(cx, sprop, obj, obj2, vp)) {

        JS_LOCK_OBJ_VOID(cx, obj2, js_DropScopeProperty(cx, scope, sprop));

        return JS_FALSE;    /* <- HERE COMES */

    }

        .

}



"SPROP_GET" macro fails.

/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

Comment 6

[John Morrison]

confirming this bug. javascript: URLs entered into urlbar (location: bar)
do not work -- mac/linux/win32 20000510nn

Comment 7

[leger]

Adding crash keyword

Comment 8

[Andreas Franke (gone)]

Changing Platform/OS from Mac/to All per John's comment.

I think the term "crash" is used for situations where the complete mozilla
application stops working, e.g. a complete lockup or segmentation violation.
If I understand you correctly, the only case where you observe a crash is the
lockup/freeze caused by
	javascript:window.location="http://www.mozilla.org";
which is covered by bug 37463, whereas other javascript: URLs entered in the
location bar produce an error message in the console, but the mozilla
application is still usable.

Assuming this, I'm changing the summary from "javascript: in URL-Editbox crash"
to "javascript: URLs entered in urlbar (location bar) don't work" (see John's
comment), removing the crash keyword and lowering severity from critical to
major. Please correct me if I am misunderstanding something here. Adding self
the CC list.

Note that this is not new problem: I tested javascript:window.alert( "abc" );
in M13, M14 and M15, and it did not work in any of them. The behaviour in M15
is slightly different in that the javascript error messages are not printed
to the console but only visible in the Tasks/Tools/Javascript Console window.

Comment 9

[Masahiro Iwamoto]

To Mr. Andreas Franke.



I recognized this "javascript:window. --- doesn't work situation"

first at 2000.04.23 whitch is after M15 fix.

After that, 2000.05.02, 2000.05.07, situation are the same.



In my M14 checkout, it did work.



What I mean by "javascript:window.alert("abc"); doesn't work" is that

( as far as on Macintosh ) alert window doesn't appear.



With debugger, I found JavaScript Interpret fails in getting some PROPERTY.

After that, in nsIDocumentLoaderObserver::OnEndDocumentLoad()

an ASSERTION raised,

'cause he tries to get host from "window.alert(\"abc\");"

and SimpleURI::GetHost() method is not implemented.



But I think main reason of not appearing alert is

JavaScript Interpret failure.



And maybe by same reason,

javascript:window.open("http://www.mozilla.org");

cannot display any window on Macintosh

with above mentioned three version.



/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

I'm trying to embed mozilla in macintosh program,

and want to execute javascript command from

main program by nsIWebNavigation::LoadURI.

/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

Comment 10

[Prashant Desale]

Marking nsbeta2.

Comment 11

[ekrock's old account (dead)]

Turns out that lack of support for javascript: URLs (bug 34667 or bug 38537, not 
precisely sure which) blocks Andrei from implementing the default plug-in. (The 
one that's invoked when the user lacks the necessary plug-in to see content.) 
Raising severity to blocker and setting milestone to M17. 

The other thing to keep in mind is that since javascript: URLs in the Location 
bar and HREFs aren't working, the JavaScript they would normally execute is not 
running on Mozilla/Netscape 6, so we're not exposing other bugs that will be 
revealed when that JavaScript is run. Nor are we enabling content developers to 
notice when they're using non-standards-compliant JavaScript in those URLs that 
they need to upgrade.

As a result, this bug should be a hard nsbeta2 stopper.

Comment 12

[rickg]

This is needed for beta2; giving PDT approval.

Comment 13

[vidur (gone)]

The following patch fixes a crash I saw associated with javascript: URLs. The 
remaining problems are addressed by bug 31818.

Index: nsJSProtocolHandler.cpp
===================================================================
RCS file: /cvsroot/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp,v
retrieving revision 1.46
diff -r1.46 nsJSProtocolHandler.cpp
288c288,294
<         *aInputStream = str;
---
>         if (NS_SUCCEEDED(rv)) {
>             mResult = nsnull; // XXX Whackiness. The input stream takes owners
hip
>             *aInputStream = str;
>         }
>         else {
>             *aInputStream = nsnull;
>         }
411a418,422
>     // If the resultant script evaluation actually does return a
>     // value, we treat it as html.
>     if (NS_SUCCEEDED(rv)) {
>         rv = channel->SetContentType("text/html");
>     }

Comment 14

[Johnny Stenback (:jst)]

I just checked in Vidurs patch that fixes part of this problem, the rest of this
bug should be coverd by bug 31818 so I'm marking this as a dup of that bug.


*** This bug has been marked as a duplicate of 31818 ***

Comment 15

[Prashant Desale]

Verified Dup.