Bug 161786 [Undo] - operations with multiple, matching contexts not disposed properly
Found this problem running the workspace operations automated tests. In that suite, a marker operation that changes a bookmark and a task is performed. The operation is therefore assigned two undo contexts "bookmark" and "task". These two undo contexts are set up to "match" against the workspace context. This is done so that only task ops show up in the task list undo history, only bookmark ops show up in the bookmark view undo history, but all of the marker ops show up in the workspace undo history. The problem occurs when I attempt to dispose the workspace context. In theory, this marker operation should be disposed, since both contexts match the workspace context. In practice it doesn't happen and I get this operation "stuck" in the undo history.
bundles/org.eclipse.core.commands/src/org/eclipse/core/commands/operations/DefaultOperationHistory.java
import org.eclipse.core.runtime.OperationCanceledException;
import org.eclipse.core.runtime.Status;
/**
 * <p>
 * A base implementation of IOperationHistory that implements a linear undo and
 * redo model . The most recently added operation is available for undo, and the
 * most recently undone operation is available for redo.
 * </p>
 * <p>
 * If the operation eligible for undo is not in a state where it can be undone,
 * then no undo is available. No other operations are considered. Likewise, if
 * the operation available for redo cannot be redone, then no redo is available.
 * </p>
 * <p>
 * Implementations for the direct undo and redo of a specified operation are
 * available. If a strict linear undo is to be enforced, than an
 * IOperationApprover should be installed that prevents undo and redo of any
 * operation that is not the most recently undone or redone operation in all of
 * its undo contexts.
 * </p>
 * <p>
 * The data structures used by the DefaultOperationHistory are synchronized, and
 * entry points that modify the undo and redo history concurrently are also
 * synchronized. This means that the DefaultOperationHistory is relatively
 * "thread-friendly" in its implementation. Outbound notifications or operation
 * approval requests will occur on the thread that initiated the request.
 * Clients may use DefaultOperationHistory API from any thread; however,
 * listeners or operation approvers that receive notifications from the
 * DefaultOperationHistory must be prepared to receive these notifications from
 * a background thread. Any UI access occurring inside these notifications must