onBlur crashes with Alerts and Prompts

VERIFIED FIXED in M15

Status

()

Core
DOM: Core & HTML
P3
critical
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Syn.Terra, Assigned: saari (gone))

Tracking

({crash})

Trunk
x86
Windows 98
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
If you use the OnBlur event handler in an input field in a Form, and have the
event handler call an alert, confirm, or prompt, Mozilla will crash. I've
isolated this to just those three actions (not changing the background color,
for instance) in conjunction with the onBlur event handler. Normal alerts work okay.

I've tested this using M13, build ID 2000012520 on an Intel P233 running Win98.
This crashes everytime I've tried it. The above URL takes you to a page which
gives you three ways to kill your browser.

Updated

18 years ago
Severity: normal → critical

Comment 1

18 years ago
Thanks for setting up the great test page!

This looks like a problem with the Document Object Model API, not the JavaScript
language engine.  (The DOM exposes methods to the JS engine, but isn't the same
as the JS engine.)

Reassigning to the DOM component.
Assignee: mccabe → vidur
Component: Javascript Engine → DOM Level 0
QA Contact: rginda → desale

Comment 2

18 years ago
I can't reproduce an immediate crash (the bug report implies that there is one), 
but I do eventually get one after spending a few seconds trying to click through 
the alert dialogs brought up (stack below).

There's actually a second problem. I've attached a simpler test case that 
doesn't get us into the infinite dialog case in 4.x that the original one does. 
However, we do get into that case in Mozilla, even with the simpler test case. 

Passing this one along to saari since he's the focus king. 

nsEventStateManager::SendFocusBlur(nsEventStateManager * const 0x027b80f0, 
nsIPresContext * 0x02ee68f0, nsIContent * 0x02eeac20) line 2163 + 33 bytes
nsEventStateManager::SetContentState(nsEventStateManager * const 0x027b80f0, 
nsIContent * 0x02eeac20, int 2) line 2022
nsXULElement::SetFocus(nsXULElement * const 0x02eeac2c, nsIPresContext * 
0x02ee68f0) line 3735
nsEventStateManager::ChangeFocus(nsIContent * 0x02eeac20, nsIFrame * 0x0226923c, 
int 1) line 1600
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x027b80f0, 
nsIPresContext * 0x02ee68f0, nsGUIEvent * 0x001124f4, nsIFrame * 0x0226923c, 
nsEventStatus * 0x00112400, nsIView * 0x02ee63f0) line 776
PresShell::HandleEvent(PresShell * const 0x02ee0e74, nsIView * 0x02ee63f0, 
nsGUIEvent * 0x001124f4, nsEventStatus * 0x00112400) line 2852 + 43 bytes
nsView::HandleEvent(nsView * const 0x02ee63f0, nsGUIEvent * 0x001124f4, unsigned 
int 28, nsEventStatus * 0x00112400, int & 0) line 797
nsViewManager::DispatchEvent(nsViewManager * const 0x02ee66e0, nsGUIEvent * 
0x001124f4, nsEventStatus * 0x00112400) line 1705
HandleEvent(nsGUIEvent * 0x001124f4) line 69
nsWindow::DispatchEvent(nsWindow * const 0x02ee62c4, nsGUIEvent * 0x001124f4, 
nsEventStatus & nsEventStatus_eIgnore) line 507 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x001124f4) line 528
nsWindow::DispatchMouseEvent(unsigned int 324, nsPoint * 0x00000000) line 3487 + 
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 324, nsPoint * 0x00000000) line 
3705
nsWindow::ProcessMessage(unsigned int 515, unsigned int 1, long 4325571, long * 
0x00112794) line 2781 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x00020c84, unsigned int 515, unsigned int 1, long 
4325571) line 693 + 27 bytes
USER32! 77e71250()
nsRe
Assignee: vidur → saari

Comment 3

18 years ago
Created attachment 4769 [details]
simpler test case
(Assignee)

Comment 4

18 years ago
Okay, I don't see crashes in the focus code, but in other places like 
nsEventListenerManager and nsWebshellWindow. Once I fix these (they're just 
missing null checks), I cannot close the alert at all.

CCing danm in the hope that he has some ideas about this.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M15

Comment 5

18 years ago
Adding "crash" keyword.
Keywords: crash
(Assignee)

Comment 6

18 years ago
Fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 7

18 years ago
Verified with 2000-02-14-09.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.