97166 - Crash with Warpzilla and XCenter/XWorkplace

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Mike Kaply [:mkaply]]

When running XWorkPlace with Warpzilla, closing Windows crashes.

Here is the explanation from Aaron Reed:

The problem turned out to be focus related.  The trap was happening in
nsEventStateManager::PreHandleEvent when handling a NS_DEACTIVATE event.  The
problem is that the focusController was queried and it came back null.  Though
there was an effort to check for null, it was still used later on in the code.
The real problem is what made the focus controller null.

The focus controller was freed up by a call to DocumentViewerImpl::Destroy when
it set the ScriptGlobalObject to null.  It is being destroyed because the 
preferences
window is going away.  So the problem now became why were we processing a
NS_DEACTIVATE event during the destruction of the preferences window and why 
does
this only happen with XCenter.

XCenter is unique in that it is a workplace shell object so the frame window, in
addition to subclassing the frame proc for XCenter, it is also subclassed by the
workplace shell when the call to wpRegisterView is called.  The XCenter frame 
proc
subclasses the frame and handles the WM_ADJUSTWINDOWPOS message.  It looks to 
see
if SWP_ACTIVATE is set and if it is, that flag is removed and SWP_DEACTIVATE is 
added.
Then this message returns AWP_DEACTIVATE and doesn't pass the WM_ADJUSTWINDOWPOS 
on
to its def proc.

When the WinDestroyWindow comes through for the preferences frame, pmwin does 
some
checking to see who should get the new focus.  Because the XCenter frame handles 
WM_ADJUSTWINDOWPOS this way, it causes some problems such that a "do or die" 
test
is made in pmwin to make sure that SOMEONE gets the focus because the frame that
is getting destroyed still has the focus at the point fo the test.  A window is 
found.
So during the processing of the WinDestroyWindow an effort is made to deactivate 
the
current focus window and then activate the new focus window.  During this 
deactivation,
a WM_ACTIVATE (mp1=0 to show it is deactivating this window) is sent to the 
preferences
frame who then sets up a NS_DEACTIVATE event which eventually leads to our trap.

The fix was put into WM_ACTIVATE so that if we determine that a deactivation is
occurring and the frame is the window currently going through destroy 
(gHwndBeingDestroyed)
or is a child of this window, then we do NOT set the gDeactivate flag.  Then the
NS_DEACTIVATE processing won't happen and we won't trap.

Attaching Diff

Comment 1

[Mike Kaply [:mkaply]]

Attachment: Fix for bug

Comment 2

[Mike Kaply [:mkaply]]

Fix checked in

Comment 3

[Mike Kaply [:mkaply]]

We haven't been hearing of this...