Closed Bug 56355 Opened 24 years ago Closed 24 years ago

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

Categories

(SeaMonkey :: General, defect, P1)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 55460

People

(Reporter: mpercy, Assigned: asa)

References

(
URL
)

Details

(Keywords: crash)

Attachments

(1 file)

HTML file containing javascript alert link
192 bytes, text/html
Details
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 -> javascript:alert('test'); 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 button. 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.
Priority: P3 → P1
Sorry for the spam, I am new to BugZilla -- changed to P1, security issue (javascript crasher)
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: <HTML> <TITLE></TITLE> <SCRIPT> alert('Hi') </SCRIPT> </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: WARNING: 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
Status: UNCONFIRMED → NEW
Component: Javascript Engine → Browser-General
Ever confirmed: true
QA Contact: pschwartau → doronr
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.
worksforme win98 2000101212.
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.
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.
*mass spam* adding crash keyword to all crash bugs
Keywords: crash
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
pschwartau, I see this also with today's trunk builds. Who do you think should be looking into this?
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 bytes 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 bytes 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 bytes 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() 00ac3c50()
adding danm in case he can help.
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 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
*** Bug 58765 has been marked as a duplicate of this bug. ***
vrfy dup
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: