11966 - [PP]Dismissing xpinstall confirmation dialog results in crash

Status: VERIFIED WORKSFORME

(Core Graveyard :: Installer: XPInstall Engine, defect, P2)

Description

[Jimmy Lee]

Build: 8/16/99 SeaMonkey build

1. From http://jimbob/trigger2.html, trigger any jar file
2. Click either OK or Cancel button from dialog "Attempting to download and
   install software.  Do you feel lucky, punk?"
3. The browser window becomes the active window.  The dialog appears behind
   browser window if it is on top of it
4. Click on dialog to make it active
5. Click OK or Cancel button again

RESULT:
Crash from Windows only.  Install.log is not created.

TalkBack Incident ID = 12488678
Call Stack:    (Signature = nsEventStateManager::SendFocusBlur 840689d3)
nsEventStateManager::SendFocusBlur
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line
1234]
nsEventStateManager::SetContentState
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line
1129]
nsHTMLInputElement::SetFocus
[d:\builds\seamonkey\mozilla\layout\html\content\src\nsHTMLInputElement.cpp,
line 433]
nsEventStateManager::ChangeFocus
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line
785]
nsEventStateManager::PostHandleEvent
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line
243]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1886]
nsView::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 835]
nsView::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 820]
nsView::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 820]
nsView::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 820]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1611]
HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 67]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 502]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 523]
nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3273]
ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3466]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2529]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 572]
USER32.dll + 0x1820 (0x77e71820)
0x00b10249

EXPECTED RESULT:
No crash.  Installation is completed.

NOTE:
I was able to get it to install twice.  I didn't do anything noticeably
different.

Comment 1

[Jimmy Lee]

If the confirm dialog is called from an HTML page, it does not crash when OK or
Cancel is selected.  See http://jimbob/bugs/confirm_it.html

Comment 2

[Cathleen]

This is a intermittent crash.  Not reproducible in debug build, and not always
reproducible in release build.

Comment 3

[Cathleen]

David, can you take a look at this problem?  We think it's general cofirm dialog
problems.

The trick is... It's only reproducable in release build, not in our debug build.

Comment 4

[davidm]

I am reassigning to danm since I noticed that there is something wrong with the
modality in the bad case. I am able to swith to the browser window (but not type
anything ) while the modal window is up. Other QA people have reported similiar
problems although I don't have a test case handy. The code is crashing because
mCurrentFocus is NULL and after it gets assigned to mCurrentTarget, the addref
fails. Maybe that code should be handling this bad case but I don't know.

Comment 5

[Daniel Veditz [:dveditz]]

Can we change the Summary to delete the word "xpinstall", or does this only
happen in xpinstall's use of the confirmation dialog? (and change the
component, too).

If it ONLY happens in xpinstall it's probably not worth a lot of brain cells
since this dialog will get replaced with a custom modal dialog. Use of the
stock confirm() dialog is temporary. But if the problem is in the stock
confirm() dialog then other people should be running into this and the
description should match to prevent dupe bugs.

Comment 6

[Jimmy Lee]

The crash has not happened for several builds.  Changing Severity from Blocker
to Normal.

Comment 7

[Peter Trudelle]

I cannot reproduce this using today's opt bits on Win98, is it still happening?
Does anyone think we need to hold M11 for this?

Comment 8

[Peter Trudelle]

Moving to M12

Comment 9

[Peter Trudelle]

Mass-moving non-PDT+ bugs to M13

Comment 10

[leger]

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine

Comment 11

[Dan M]

Work has been done recently on surviving window closures. I've personally never seen
this bug, though I spend as little time as possible in non-debug builds. People are saying
it seems to have evaporated. Let's make it official. I call your "cannot repro" and raise you
one "works for me."

Comment 12

[Jimmy Lee]

Build 2000-01-03-09-M13(WIN), 2000-01-03-08-M13(MAC), 2000-01-03-08-M13(LINUX)

I still have not seen this in months.  Marking Verified.