Description Jeff Brown 2002-04-15 17:30:55 EDT

Please refer to TextMergeViewer.updateContent().

After updating the contents of the viewer, the method posts a runnable to the 
event loop asynchronously to update the selection later on, presumably after 
the resize has occurred.  This runnable implictly assumes that the state
of the viewer is the same as it was before.

What happens if setDocument() causes a modal context to be created?  Suppose 
the runnable from a previous execution of updateContent() is still pending on 
the event queue.  Then the runnable will be run from 'inside' setDocument() 
with the viewer in an inconsistent state.  Specifically, fChangeDiffs may be 
null, resulting in a NullPointerException.

The problem is that TextMergeViewer does not ensure that its posted runnables 
have completed before a state-altering operation occurs.  Conversely, the 
runnable does not perform a sanity check before executing.

P.S. Why a modal context here?  Fetching the contents of the resources to 
compare could result in a progress dialog or error recovery prompt being 
displayed.  We (VCM) were considering popping up a progress monitor dialog 
while fetching the contents of remote resources since the framework does not 
currently supply IStreamContentAccessor's getContents() with a progress monitor.