javascript alert() crashes hangs browser, no alert box displayed



18 years ago
13 years ago


(Reporter: Michael Percy (obsolete email address), Assigned: asa)



Windows NT

Firefox Tracking Flags

(Not tracked)




(1 attachment)

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
BuildID:    2000101108

As simple as the summary says: try entering into the browser the string -> 
and the browser hangs and crashes. Tested on NT4, on both M18 and 10/11/2000 
nightly builds.

Reproducible: Always
Steps to Reproduce:
1. Type javascript:alert('I am asking for it!'); into the address bar
2. Hit <enter>

Actual Results:  Mozilla hung, and I was forced to kill the browser manually.

Expected Results:  Display an alert box saying 'I am asking for it!' with an OK 

Seems like Moz is making an (invisible?) modal window that cannot be interacted 
with. Not just an address-bar thing, BTW, this is a real javascript issue that 
happens anytime an alert box is popped up, whether from inline JS or otherwise. 
Also affects confirm() and prompt(). Too bad this got into M18.


18 years ago
Priority: P3 → P1

Comment 1

18 years ago
Sorry for the spam, I am new to BugZilla -- changed to P1, security issue 
(javascript crasher)

Comment 2

18 years ago
Confirming on WinNT with Mozilla debug trunk build 2000-10-11
The browser completely hangs if you key javascript: alert('Hi') in the 
URL bar and hit enter. Or if you launch Mozilla from the debug console via: 

               ./mozilla javascript:alert('Hi')

No problem, however, if we type this in the URL bar: 

               javascript: 'Hi'

And no problem running this HTML: 




Cannot reproduce the bug with Linux debug trunk build same date, 2000-10-11.
Cannot reproduce with WinNT Mozilla binary MN6 2000100908.

NOTE: I am seeing this in the debug console as Mozilla is launching:

   XBL load did not complete until after document went away! Modal dialog bug? 
   file: d:\mozilla\layout\xbl\src\nsXBLService.cpp, line 324

Could that be related to this bug? 

This does not seem to be a problem with JS Engine; reassigning to 
Browser-General for further triage. Not sure who is responsible for
interpreting the JavaScript from the URL bar and bringing up the alerts.
Assignee: rogerl → asa
Component: Javascript Engine → Browser-General
Ever confirmed: true
QA Contact: pschwartau → doronr

Comment 3

18 years ago
Mozilla produces expected results under Mac OS 9.0.4, Moz trunk build 2000101215.

worksforme under Mac OS, so might be Win NT-only bug.

Comment 4

18 years ago
worksforme win98 2000101212.

Comment 5

18 years ago
Created attachment 17033 [details]
HTML file containing javascript alert link

Comment 6

18 years ago
Confirmed on Win 95 Build 2000101014

Eventually does return alert, but may take as much as 5 minutes.

Window behavior is as if the modal was showing.  Other windows are unaffected.
Browsing to another location in other window sometimes speeds up process.  Also,
window with alert cannot be <Alt>+<Tab>ed to.

Note: attachment shows error with links, too. Not just URL bar.

Comment 7

18 years ago
Unable to confirm with javascript:alert('I am asking for it!'); in the URL bar
or the attached testcase.  No hang, no crash.  Alert is displayed as expected.
tested with 101308 mozilla trunk build.
No problems under Windows 2000 build 2000101320.
The testcase works without problems.

Comment 9

18 years ago
*mass spam*
adding crash keyword to all crash bugs 
Keywords: crash


18 years ago
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 10

18 years ago
MN6-branch commercial build 2000101608 on WinNT - WORKSFORME 
2000101608 MTrunk build - Crash. Not resolved on trunk. This may be a recent 
change that never got into the NS6 branch. Reopening bug.
Resolution: WORKSFORME → ---

Comment 12

18 years ago
Using trunk Mozilla builds 2000101608 on WinNT, Linux.
Confirming what Michael has found: behavior is different from the MN6 branch.

METHOD: key javascript: alert('Hi') in the URL bar and hit Enter

WinNT: the browser hangs and becomes completely unreponsive
Linux: the browser doesn't hang, but the alert doesn't come up either.

Again, this is different than the MN6 branch, where it works fine
on both platforms. 

Comment 13

18 years ago
pschwartau, I see this also with today's trunk builds.  Who do you think should
be looking into this?

Comment 14

18 years ago
Here is a WinNT stack trace from a trunk build made 2000-10-11.
At the top, it shows function calls from nsXULWindow, nsWebShellWindow,
and nsChromeTreeOwner... not sure who is the owner of these.

USER32! 77e72ada()
nsXULWindow::ShowModal(nsXULWindow * const 0x04fc5f40) line 230 + 31 bytes
nsWebShellWindow::ShowModal(nsWebShellWindow * const 0x04fc5f40) line 1113
nsChromeTreeOwner::ShowModal(nsChromeTreeOwner * const 0x04fc4d70) line 182
GlobalWindowImpl::OpenInternal(GlobalWindowImpl * const 0x02f5c8f0, JSContext * 
0x02f5c6d0, long * 0x02c66ec0, unsigned int 4, int 1, nsIDOMWindowInternal * * 
0x0012eb04) line 3082
GlobalWindowImpl::OpenDialog(GlobalWindowImpl * const 0x02f5c8f4, JSContext * 
0x02f5c6d0, long * 0x02c66ec0, unsigned int 4, nsIDOMWindowInternal * * 
0x0012eb04) line 2021
nsCommonDialogs::DoDialog(nsCommonDialogs * const 0x02b04b40, 
nsIDOMWindowInternal * 0x02f5c8f4, nsIDialogParamBlock * 0x04fc7770, const char 
* 0x00f08738) line 453 + 49 bytes
nsCommonDialogs::Alert(nsCommonDialogs * const 0x02b04b40, nsIDOMWindowInternal 
* 0x02f5c8f4, const unsigned short * 0x04fc7290, const unsigned short * 
0x0012ec84) line 70 + 27 bytes
nsDOMWindowPrompter::Alert(nsDOMWindowPrompter * const 0x043c83e0, const 
unsigned short * 0x00000000, const unsigned short * 0x0012ec84) line 1845 + 55 
nsSingleSignOnPrompt::Alert(nsSingleSignOnPrompt * const 0x043c9f40, const 
unsigned short * 0x00000000, const unsigned short * 0x0012ec84) line 431
GlobalWindowImpl::Alert(GlobalWindowImpl * const 0x03e391c4, JSContext * 
0x03e3ae70, long * 0x02c2ffc4, unsigned int 1) line 1490 + 50 bytes
WindowInternalAlert(JSContext * 0x03e3ae70, JSObject * 0x00da37e0, unsigned int 
1, long * 0x02c2ffc4, long * 0x0012ee00) line 3000 + 38 bytes
js_Invoke(JSContext * 0x03e3ae70, unsigned int 1, unsigned int 0) line 790 + 23 
js_Interpret(JSContext * 0x03e3ae70, long * 0x0012fa18) line 2589 + 15 bytes
js_Execute(JSContext * 0x03e3ae70, JSObject * 0x00da37e0, JSScript * 0x04fc7d20, 
JSFunction * 0x00000000, JSStackFrame * 0x00000000, unsigned int 0, long * 
0x0012fa18) line 962 + 13 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x03e3ae70, JSObject * 0x00da37e0, 
JSPrincipals * 0x04fabc90, const unsigned short * 0x0012fb10, unsigned int 11, 
const char * 0x00000000, unsigned int 0, long * 0x0012fa18) line 3146 + 27 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x03e39150, const 
basic_nsAReadableString<unsigned short> & {...}, void * 0x00da37e0, nsIPrincipal 
* 0x04fabc8c, const char * 0x00000000, unsigned int 0, const char * 0x00000000, 
basic_nsAWritableString<unsigned short> & {...}, int * 0x04ecfcf0) line 583 + 68 
nsEvaluateStringProxy::EvaluateString(nsEvaluateStringProxy * const 0x04fb7690, 
char * * 0x04ecfcec, int * 0x04ecfcf0) line 167 + 64 bytes
XPTC_InvokeByIndex(nsISupports * 0x04fb7690, unsigned int 4, unsigned int 2, 
nsXPTCVariant * 0x04fbe230) line 139
EventHandler(PLEvent * 0x04fbfb40) line 513 + 41 bytes
PL_HandleEvent(PLEvent * 0x04fbfb40) line 576 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ac3c50) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00c90312, unsigned int 49372, unsigned int 0, 
long 11287632) line 1054 + 9 bytes
USER32! 77e71820()

Comment 15

18 years ago
adding danm in case he can help.

Comment 16

18 years ago
I think that this is a duplicate of bug 55460.  If I'm an idiot and these aren't
the same thing please reopen.

*** This bug has been marked as a duplicate of 55460 ***
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 17

18 years ago
*** Bug 58765 has been marked as a duplicate of this bug. ***

Comment 18

17 years ago
vrfy dup
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.