Find/Replace overlay: handle the case when moving editor between windows

[Wittmaxi]

When moving the targeted editor between different windows, the overlay is closed to allow a retargetting.

fixes #1945

[github-actions]

Test Results

 1 815 files  ±0   1 815 suites  ±0   1h 32m 28s ⏱️ - 5m 32s
 7 677 tests ±0   7 449 ✅ +1  228 💤 ±0  0 ❌  - 1 
24 192 runs  ±0  23 443 ✅ +1  749 💤 ±0  0 ❌  - 1 

Results for commit d121c1e. ± Comparison against base commit a5689de.

♻️ This comment has been updated with latest results.

[iloveeclipse]

With this PR overlay never appears for me on Linux, so Ctrl+F is broken completely.

[Wittmaxi]

@iloveeclipse can you please confirm that this PR now opens on Linux?

[iloveeclipse]

@iloveeclipse can you please confirm that this PR now opens on Linux?

You mean not that PR opens but that Ctrl+F shows an overlay now? Yes, it does.
#1951 is still visible with it though...

[Wittmaxi]

@iloveeclipse very good!
This PR cannot fix #1915, I have implemented a fix in #1975 - please tell me whether that fixes the bug!

[Wittmaxi]

@Wittmaxi

[HeikoKlare]

This results in multiple calls to super.open(), as it is already called in a subsequent if block. Why is an additional call necessary? At least, I would only expect one of the calls to be necessary.

[HeikoKlare]

This will result in always creating a new overlay, so all the logic in the overlay used for re-opening it will be unused, won't it? Why is this necessary?

[Wittmaxi]

@HeikoKlare so the logic here is:

if the Overlay senses that it's viewPart is not the same anymore, it closes itself and disposes itself. The action doesn't know about this and should absolutely not open the overlay and instead create a new one.

I am not sure what I thought when I implemented this a few weeks ago, but it seems to be far more complex than It should be. I have made the implementation more "naive" and in my tests, the implementation still works perfectly!

[HeikoKlare]

Sorry, I still don't get it. With the current implementation, the overlay is always thrown away after closing it (before it was just reopened). From my understanding, this is only necessary to ensure that when the parent shell changes, the overlay is reinitialized. That is, however, a responsibility of the overlay and not of its consumers. With this implementation, creating a new consumer of the overlay would requirement them to know about the necessity to reinitialize the overlay upon parent shell changes.

My expectation of flows/responsibilities is as follows:

• the overlay tracks whether it's parent shell has changed (as implemented in the positionToPart() method)
• upon changes of the parent shell, the overlay closes itself (as also implemented in the positionToPart() method), then updates the parent shell via setParentShell() (which requires the dialog to be closed, as the current shell must be disposed) and reopens itself.

The latter two actions are currently the responsibility of the consumer. So the consumer must be aware that there will be events that close the overlay and require a new overlay to be created (instead of reopening the existing one).

[Wittmaxi]

I completely agree that we should

1. be specific about the overlay closing on parent shell change
2. give the client a way of listening in on that event

A few technical limitations made the solution not very straightforward

1. obviously, we do not want to add a new method to the TextEditor
2. The overlay needs to be able to set the overlay object in the FindReplaceAction

I have thus come up with this solution which clearly states as API contract that the overlay closes itself when it detects that the parent shell is changed (i.e. the targeted viewpart was moved to another window)
By adding a listener for this, I ensure that the overlay object in the FindReplaceAction is always good for use.

I have not dropped the commit for the old change and I will fix the merge errors once I have received confirmation that this is the direction we should move to @HeikoKlare

[HeikoKlare]

Instead of using the callback provided by the consumer, just internally updating the target seems to work for me:

	getShell().getDisplay().asyncExec(() -> {
		close();
		setParentShell(targetPart.getSite().getShell());
		open();
		targetPart.setFocus();
	});

Can you try this and check whether it also works?

[Wittmaxi]

I get this, which is close enough but not perfect. We need to make sure that launching the asynchronous function is idempotent. I can do that for example by setting a boolean flag once it is called and resetting it once the new overlay is actually opened.

I will do that in my office hours

[HeikoKlare]

I've tested this on all three OS, in particular with the problematic scenarios to be addressed by this change. I did not find any issues so far, so let's have this merged.