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: