[kpkoch - Tue Aug  7 13:53:02 2007]:

> Actually, the bug was that the size & position were being remembered
> at the wrong time.
> 
> The good news is that the patch below fixes the problem.  The bad news
> is that it doesn't offer any insight into the display inconsistency
> bugs.

WM_EXITSIZEMOVE is unfortunately not a good message to rely on for
notifications of window size/position changes.  It is used to notify a
window that it is exiting the moving/sizing modal loop.  This loop is
used when the user is dragging a window around or using system menu and
cursor keys to reposition windows.  However, windows can be repositioned
using other means as well, such as invoking the explorer window layout
commands (cascade windows, tile vertically/horizontally, etc..) and
third party desktop managers and some implementations of virtual desktop
managers.  WM_MOVE is used to notify the window of size/position changes
in all these situations, which is why that message was triggering the
code which saves the window position.  A problem with WM_MOVE is that if
the user preferences enable dragging the whole window during moves and
resizes, the window may receive multiple WM_MOVE messages in rapid
succession.  This is also the case with some third party desktop
switchers that try to animate automatic window re-positioning.  To
prevent Network Identity Manager from attempting to save each and every
intermediate window position, we don't directly save the position while
handling WM_MOVE.  Instead we use a timer to wait until the torrent of
WM_MOVE messages end.

The actual bug was that we weren't saving the window position if the
user switched the display mode before this timeout expired.  By the time
the timer fired, the window would be in a different position.  A fix
would be to save the position and cancel the pending timer if a mode
switch is requested.

- Asanka Herath
Secure Endpoints Inc.