Bug 559539 - WorkspaceUndoMonitor is too aggressive
Summary: WorkspaceUndoMonitor is too aggressive
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 4.14   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 4.16 M3   Edit
Assignee: Vladimir Piskarev CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-25 10:53 EST by Vladimir Piskarev CLA
Modified: 2020-04-28 05:05 EDT (History)
3 users (show)

See Also:


Attachments
Project for reproducing the issue (1.85 KB, application/zip)
2020-01-25 10:53 EST, Vladimir Piskarev CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Piskarev CLA 2020-01-25 10:53:36 EST
Created attachment 281598 [details]
Project for reproducing the issue

0. Install Wild Web Developer from SimRel 2019-12 into Eclipse SDK 4.14.

1. Import the attached project `foo`.
2. Open `Foo.java`.
3. Refactor -> Rename... on `Foo` and rename `Foo` to `Bar`.
4. Source -> Generate Element Comment on `Bar`.
5. Open `plugin.xml`.
6. Slowly start typing an XML comment, `<!--`.
7. Activate `Package Explorer` view.
8. Try to Edit -> Undo Rename Type. Observe that it does not do anything.

The reason is that WorkspaceUndoMonitor has flushed the history for the workspace undo context at step 6.

More Information:
Currently, WorkspaceUndoMonitor considers any resource change a change worth tracking. That includes marker changes. Unlike the usual Eclipse approach where marker changes are produced by project builders, a new breed of tools based on the Language Server Protocol (LSP) tend to produce marker changes on each document change (e.g., typing). This quickly increments the number of resource changes tracked by WorkspaceUndoMonitor to CHANGE_THRESHHOLD (currently, 10), which causes checking the operation history.

Possible Fix:
As stated by a comment in the WorkspaceUndoMonitor#getResourceChangeListener() method, "We can be more specific later if warranted". I propose to ignore any marker changes in the resource change listener.
Comment 1 Lars Vogel CLA 2020-01-25 10:57:37 EST
Sounds reasonable Vladimir. Can you upload a Gerrit for that?
Comment 2 Vladimir Piskarev CLA 2020-01-25 11:15:19 EST
(In reply to Lars Vogel from comment #1)
> Sounds reasonable Vladimir. Can you upload a Gerrit for that?

Thanks for the quick response Lars. I will try to do it during the upcoming week.
Comment 3 Eclipse Genie CLA 2020-01-27 11:22:16 EST
New Gerrit change created: https://git.eclipse.org/r/156658
Comment 4 Alexander Fedorov CLA 2020-01-28 10:10:55 EST
May be we should move it to the LSP4E domain? The uploaded change may fix the described scenario, but it adds more complexity to the WorkspaceUndoMonitor that already has some distance from being perfect.
Comment 5 Mickael Istria CLA 2020-01-28 10:24:26 EST
Isn't there a flag or something to describe that a given Workspace operation shouldn't be considered in the undo stack? Indeed, for the case of LSP4E at least, the markers don't need to affect the undo history.
I see for instance POST_AUTO_BUILD is ignored while POST_BUILD is honored, so it seems to imply that only operations that are triggered by users should be part of the undo stack. It usually not the case for marker manipulation, so it would seem OK to me to ignore marker changes from the undo stack in general.
Comment 6 Lars Vogel CLA 2020-02-28 07:05:15 EST
Setting to 4.16 M1 so that I get reminded to review.
Comment 8 Lars Vogel CLA 2020-04-28 04:36:39 EDT
Mickael, as you merged this, please add to N&N.

Vladimir, sorry for never keeping my promisse to review your change. Looks like your change convinced Mickael. :-)
Comment 9 Mickael Istria CLA 2020-04-28 04:41:19 EDT
(In reply to Lars Vogel from comment #8)
> Mickael, as you merged this, please add to N&N.

This is a bugfix. It IMO doesn't qualify for N&N.
Comment 10 Vladimir Piskarev CLA 2020-04-28 04:59:40 EDT
(In reply to Lars Vogel from comment #8)
> Vladimir, sorry for never keeping my promisse to review your change. Looks
> like your change convinced Mickael. :-)

Thank you! :-)
Comment 11 Lars Vogel CLA 2020-04-28 05:05:46 EDT
(In reply to Mickael Istria from comment #9)
> (In reply to Lars Vogel from comment #8)
> > Mickael, as you merged this, please add to N&N.
> 
> This is a bugfix. It IMO doesn't qualify for N&N.

Fine for me, I just wanted to avoid that we surprise users / adapters with an undocumented behaviour change. But I leave the decision to you.