Fix flaky LinkHelperTest.testLinkHelperEditorActivation

When link-with-editor is enabled, the IPartListener in LinkEditorAction
scheduled updateSelectionJob from both partActivated and partBroughtToTop.
Both events fire for the same editor activation, so under normal timing the
second schedule() call merely resets the job timer and the job runs once.

However, on slow machines (CI on Linux/GTK) the two events can fire more
than LINK_HELPER_DELAY (120 ms) apart, causing the job to complete from the
first event and then be rescheduled and run again from the second. This
results in findSelection() being called twice, breaking the assertion
assertEquals(1, findSelectionCount) in testLinkHelperEditorActivation.

Fix: remove the job scheduling from partBroughtToTop. The partActivated
event is the correct signal for "an editor became active", which is exactly
what the link-with-editor feature needs to track.

Fixes #1338

Author: HeikoKlare

bundles/org.eclipse.ui.navigator/src/org/eclipse/ui/internal/navigator/actions/LinkEditorAction.java

@@ -149,9 +149,12 @@ public void partActivated(IWorkbenchPart part) {
 
 			@Override
 			public void partBroughtToTop(IWorkbenchPart part) {
-				if (part instanceof IEditorPart && !ignoreEditorActivation) {
-					updateSelectionJob.schedule(NavigatorPlugin.LINK_HELPER_DELAY);
-				}
+				// Do not schedule a selection update here:
+				// 1. when the part is just brought to top (programmatically) but not activated,
+				// no link update is expected.
+				// 2. scheduling from both partActivated and partBroughtToTop can cause
+				// the job to run twice when the two events fire more than
+				// LINK_HELPER_DELAY apart (intermittent on slow machines).
 			}
 
 			@Override