NavigationHistoryEntry logic can lead to entrys being merged together when they shouldn't be

[Greglar4]

In the mergeInto method of NavigationHistoryEntry, it checks if the EditorInput equals the EditorInput of the currentEntry parameter, and merges the NavigationHistoryEntries if so.

However, in our use case, we have two different editors whose EditorInputs are FileEditorInputs, and they can be editors for the same file. The equals method in FileEditorInputs returns true if the two FileEditorInputs are associated with the same underlying file.

Therefore, the NavigationHistoryEntries are merged together if the user navigates between two editors which edit the same underlying file, even though these two editors are very different editors, and should be treated as different editors for navigation purposes.

[merks]

Maybe org.eclipse.ui.internal.NavigationHistoryEntry.mergeInto(NavigationHistoryEntry should be implemented like this to also take the editor ID into account:

	/**
	 * Merges this entry into the current entry. Returns true if the merge was
	 * possible otherwise returns false.
	 */
	boolean mergeInto(NavigationHistoryEntry currentEntry) {
		if (Objects.equals(editorInfo.editorInput, currentEntry.editorInfo.editorInput)
				&& Objects.equals(editorInfo.editorID, currentEntry.editorInfo.editorID)) {
			if (location != null) {
				if (currentEntry.location == null) {
					currentEntry.location = location;
					location = null;
					return true;
				}
				return location.mergeInto(currentEntry.location);
			} else if (currentEntry.location == null) {
				return true;
			}
		}
		return false;
	}

It's really easy to set up a development environment to contribute a pull request:

https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md#create-an-eclipse-development-environment

[Greglar4]

I could contribute a pull request with this change. Would it be at all possible for this to be downbranched into Eclipse 2020-12? If not, can you think of a way we could implement this change ourselves? I was looking at it and it seemed that to edit the NavigationHistoryEntry we would have to edit NavigationHistory, which then seemed to require that we go all the way up and implement our own Workbench.

[mickaelistria]

@Greglar4 Platform project requires that incoming changes are based on top of master first. Once approved for master, we can on request backport the change to older branches; however Eclipse project wouldn't produce a new build of 2020-12/4.18 so you'd need to build it on your end anyway.

[mickaelistria]

See comment on PR, I believe assuming history is per-editor is incorrect.

[merks]

See comment on PR, I believe assuming history is per-editor is incorrect.

Keep in mind this is navigation history so when I navigate from one editor to another, I expect the arrows to just work. I see no reason to argue that this should not be the case.

[merks]

@Greglar4

Thank you for your contribution.