14517 - [PP] Crash occurs after triggering a jar and moving mouse pointer

Status: VERIFIED DUPLICATE of bug 14775

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

Description

[Jimmy Lee]

Build: 9/21/99 SeaMonkey build

1. From http://jimbob/trigger2.html, trigger any jar file
2. After jar is triggered, move the mouse pointer

RESULT:
Crash occurs.

EXPECTED RESULT:
Um..no crash, eh.

Comment 1

[Jimmy Lee]

See http://jimbob/bugs/14517Stdlog for MacsBug report.

Comment 2

[Jimmy Lee]

Sorry, I mistyped a character.

See http://jimbob/bugs/14517StdLog for MacsBug report.

Comment 3

[Samir Gehani]

This worksforme in a debug build pulled this morning. This also works for me in
this morning's optimized release build. I am not crashing when a "mouse move"
event occurs such that the mouse is outside the app chrome. Resolving as
WORKSFORME.

Comment 4

[Jimmy Lee]

Build 9/22/99

I am consistently still experiencing the crash.  I tried raising the application
memory size, but there seems to be no difference.  On occasion, I can move my
mouse pointer after a trigger without crashing.  But this appears to occur
10-20% of the time.

Comment 5

[leger]

Clearing WorkForMe resolution due to reopen.

Comment 6

[Samir Gehani]

This crash is consistently reproducible:
1> Trigger a jar.
2> Click the OK button in the confirmation dialog.
3> Leave the mouse over the confirmation dialog.
4> Voila! One fresh crash served!

The workaround is to move your mouse outside the confirmation dialog. This
should no longer block QA. Note, this is similar to a Win32 install progress
dialog crash we see. Based on further investigation it appears that this is not
an XPInstall bug per se.

Comment 7

[Jimmy Lee]

I agree that this is no longer blocking testing based on the steps described by
Samir.  Severity downgraded to Critical.

Comment 8

[Samir Gehani]

Attachment: Crash stack crawl.

Comment 9

[Samir Gehani]

This appears to be a Mac specific crash in the webshell. Attached above is a
stack crawl (gif image) from a debug build. The crash started occuring after
changes that occured between Sep 20, 12 noon and Sep 21 8 am. There were no
XPInstall changes that seemed to affect this. Reassigning to pinkerton for help.
Ping me if you need a live demo of what's going on. If reassignment was
inappropriate please reassign to the individual in a position to help us fix
this. Thanks.

Comment 10

[Mike Pinkerton (not reading bugmail)]

the stack traces here are different. one is in the event handler (mouse move),
the other is in RemoveDeleteObserver, which is a known bug (14775) assigned to
pierre. which is the correct stack trace?

i also could no dupe this bug myself. pulling the tip again to see. i'm inclined
to mark this a dupe of 14775, but will wait to hear from everyone.

Comment 11

[Samir Gehani]

My pull from late this morning still reflects my crash with the same stack trace
(the one in the gif). My vote is to mark this a dup and revisit if the fix for
14577 is still a problem with opt builds. Note, today's opt build still reflects
the crash with Jimmy's stack trace. Both crashes can be induced using the common
test detailed above.

Comment 12

[Jimmy Lee]

Build 9/27/99

I'm still crashing with today's build.  The steps to reproduce are the same as
originally documented (moouse move).  If we elect not to fix this for M10, then
we should release note this crash.

Comment 13

[Mike Pinkerton (not reading bugmail)]

ok, i get the crash now in today's build. stack trace is in the delete observer,
marking a dupe. I'll make sure the priority of 14775 is reflected to critical.


*** This bug has been marked as a duplicate of 14775 ***

Comment 14

[Cathleen]

Thanks pink!  :-)

Comment 15

[Jimmy Lee]

Build 10/4/99

I cannot duplicate the crash any more.  Any new problems will result in a new
bug report.  Marking this one Verified.

Comment 16

[leger]

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