Closed
Bug 59543
Opened 24 years ago
Closed 23 years ago
Crash closing multiple tiled dialogs (Security and JS alert)
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Tracking
()
VERIFIED
WORKSFORME
mozilla0.9.2
People
(Reporter: chrispetersen, Assigned: arik)
References
()
Details
(Keywords: crash)
Attachments
(1 file)
2.71 KB,
text/plain
|
Details |
Build: 20001110801 Platform: Windows Expected results: After submitting a form, a JS alert and security dialog appear (which are tiled on top of each other). Closing both dialogs should not crash application. What I got: Closing both dialog causes a crash. Steps to reproduce * This guaranttee's that the security warning will be displayed since the user may specified not to see this dialog. With a new user profile, this dialog should appear. 1) Create a new *profile in N6 2) Go to http://slip/projects/marvin/html/input_type_submit_onmousedn.html 3) Click on Submit Query button. 4) Two dialogs should appear (Security and JS alert). The top dialog should be security warning. Click the OK button to close dialog. 5)Now, close the JS alert dialog. 6) This should cuase the application to crash.
Reporter | ||
Comment 1•24 years ago
|
||
Here's the call stack info. Call Stack: (Signature = nsEventStateManager::SendFocusBlur ca00d1a5) nsEventStateManager::SendFocusBlur [d:\builds\seamonkey\mozilla\ layout\events\src\nsEventStateManager.cpp, line 2732] nsEventStateManager::SetContentState [d:\builds\seamonkey\mozilla\ layout\events\src\nsEventStateManager.cpp, line 2489] nsHTMLInputElement::SetFocus [d:\builds\seamonkey\mozilla\ layout\html\content\src\nsHTMLInputElement.cpp, line 625] nsEventStateManager::ChangeFocus [d:\builds\seamonkey\mozilla\ layout\events\src\nsEventStateManager.cpp, line 1891] nsEventStateManager::PostHandleEvent [d:\builds\seamonkey\mozilla\ layout\events\src\nsEventStateManager.cpp, line 905] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsPresShell.cpp, line 4939] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsPresShell.cpp, line 4853] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\ src\nsView.cpp, line 379] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\ src\nsView.cpp, line 352] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\ src\nsView.cpp, line 352] nsViewManager2::DispatchEvent [d:\builds\seamonkey\mozilla\view\ src\nsViewManager2.cpp, line 1439] HandleEvent [d:\builds\seamonkey\mozilla\view\ src\nsView.cpp, line 68] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\ widget\src\windows\nsWindow.cpp, line 686] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\ widget\src\windows\nsWindow.cpp, line 703] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\ widget\src\windows\nsWindow.cpp, line 3913] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\ widget\src\windows\nsWindow.cpp, line 4121] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\ widget\src\windows\nsWindow.cpp, line 2998] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\ widget\src\windows\nsWindow.cpp, line 959] USER32.dll + 0x1820 (0x77e71820) 0x00440050
By the way, if you move the Security popup and click OK on the JS popup first, and the security popup second, there is no crash.
Changing crasher bug milestone to mozilla0.9.
Target Milestone: --- → mozilla0.9
Comment 4•24 years ago
|
||
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Comment 5•23 years ago
|
||
Currently I can't actually get the security dialog to pop up. I'd guess its a temporary problem since if I run the same profile on my 6.0 release branch it crashes just fine, as described. Anyway, if you run it currently you get just the alert and then the browser freeezes as the submit fires behind the dialog and steals focus for the newly loading window. This is a dupe of 28467. I'm adding it as a dependency for this bug. The real bug here, though, I can at least look at in my old 6.0 tree. What I get is the attached stack trace which crashes here: nsEventStateManager.cpp, line 2740 (at the time) newWindow->GetRootCommandDispatcher(getter_AddRefs(newCommandDispatcher)); because newWindow is null. This is solidly in the saari zone. I'm going to reset the milestone to none on this so he can pick one for it. It can't be fixed until the security dialog works again anyway.
Comment 6•23 years ago
|
||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Comment 8•23 years ago
|
||
Don't think this is really a beta-stopper, moving to 0.9.2, would still take a fix this week, if you run out of stoppers to work on.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Assignee | ||
Comment 9•23 years ago
|
||
ok, will try to get it for this week then. ;-)
Assignee | ||
Comment 10•23 years ago
|
||
i can't use the site mentioned in the bug as a test cause it is inside the netscape firewall and i am in seattle... anyone know of another site or can you send me that site?
Status: NEW → ASSIGNED
Assignee | ||
Comment 11•23 years ago
|
||
ok i can view the test case now... working on this one ;-)
Updated•23 years ago
|
Summary: Closing multiple tiled dialogs (Security and JS alert) causes a crash → Crash closing multiple tiled dialogs (Security and JS alert)
Assignee | ||
Comment 12•23 years ago
|
||
so i can't duplicate this with a build as of june 11th closing WORKSFORME until someone else says they still see this problem. i created a new profile but i still don't see the js or the security dialog popup just a window saying alert and when i close that i don't get a crash.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Comment 13•23 years ago
|
||
tested on win2000 build ID: 2001061304. created a new profile. I saw the alert box, plus, the security dialog popup. Works fine. There was no browser crash. Marking bug as verified
Status: RESOLVED → VERIFIED
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•