Fix/progress service run

[fedejeanne]

Fixes #4202

This PR contains 2 commits: 1 that adds the Progress Service view, making it easier to show the buggy behavior, and 1 that fixes the issue. 1 single commit.

How to test

Either run the tests in org.eclipse.ui.tests.progress.ProgressServiceTest or use the newly added ProgressServiceView:

1. Open ProgressServiceView (Window > Show View > Other... > Progress Examples > Progress Service).
2. Check "Always run in background" (or set it under Preferences > General — the view's checkbox
   stays in sync either way).
3. Check both fork and cancelable, set a duration long enough to exceed the short-operation
   threshold (e.g. 3000 ms), click Run.

Expected behavior:

• When running the tests: they should all pass. The test that emulates the bug in IProgressService.run(fork, cancelable, runnable) behaves inconsistently #4202 is testRun_fork_cancelable_runInBackground_callFromUIThread_notPumpingUiEvents_noDialogShown.
• When using the new view as described above: No progress dialog should appear.

[github-actions]

Test Results

   858 files  ±0     858 suites  ±0   49m 53s ⏱️ - 1m 57s
 8 130 tests ±0   7 887 ✅ ±0  243 💤 ±0  0 ❌ ±0 
20 292 runs  ±0  19 638 ✅ ±0  654 💤 ±0  0 ❌ ±0 

Results for commit ca52e6d. ± Comparison against base commit f78bd54.

♻️ This comment has been updated with latest results.

[Copilot]

Pull request overview

This PR addresses issue #4202 by ensuring IProgressService.run(fork, cancelable, runnable) consistently honors the “Always run in background” preference (suppressing the modal progress dialog even for the common fork=true && cancelable=true case), and adds an examples view to reliably reproduce/observe the behavior.

Changes:

• Add an example ProgressServiceView to demonstrate/reproduce the different IProgressService.run(...) behaviors and the preference interaction.
• Fix org.eclipse.ui.internal.progress.ProgressManager#run(...) to suppress modal dialogs for all fork/cancelable combinations when “Always run in background” is enabled.
• Register the new example view in the examples plugin plugin.xml.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
examples/org.eclipse.ui.examples.job/src/org/eclipse/ui/examples/jobs/views/ProgressServiceView.java	New example view to exercise IProgressService.run(...) combinations and preference interaction
examples/org.eclipse.ui.examples.job/plugin.xml	Registers the new “Progress Service” example view
bundles/org.eclipse.ui.workbench/eclipseui/org/eclipse/ui/internal/progress/ProgressManager.java	Makes RUN_IN_BACKGROUND suppress modal progress dialogs for all fork/cancelable combinations

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[iloveeclipse]

Open ProgressServiceView (Window > Show View > Other... > Progress Examples > Progress Service

Interestingly, I don't see it if running in debugger. The org.eclipse.e4.ui.examples.job bundle is in the workspace. I assume this has to do with the "e4" way how views are contributed (progress_view.e4xmi is there), so what kind of trick one needs to see this contribution? I've already removed old workbench.xmi from .metadata/.plugins/org.eclipse.e4.workbench/, but that new view still doesn't show up.

[fedejeanne]

... so what kind of trick one needs to see this contribution?

Hm, I couldn't tell since I didn't need to use any specific trick. I am using a pretty normal debug config myself:

---

---

And the view is there for me, even in debug mode:

---

In order to use in in earlier versions of Eclipse though (to reproduce the error), I had to take the longer road:

• Export the org.eclipse.e4.ui.examples.job plugin
• Remove/relax the version constraints over org.eclipse.ui and others (in the MANIFEST.MF)
• Open the older Eclipse IDE e.g. 2025-06
• Import it as a binary: File > Import > Plug-In Development > Plug-ins and Fragments (Import As Binary projects)
• Use a Launch Configuration similar to the one I have in my current workspace i.e.:
  • Main tab: Run an application -> org.eclipse.ui.ide.workbench
  • Plug-ins tab: Launch with: -> All workspace and enabled target Plug-ins

Does this help?

[iloveeclipse]

I am using a pretty normal debug config myself

The only difference I see is that I'm running the product, but I've created new launch config that uses application and still no luck.

Not sure how much one can trust "Plug-in Registry" view in the debugger, but the picture it shows indicates on some weird dependency issue which doesn't make sense for me (all the bundles needed are in my workspace as projects in latest versions and PDE is happy at least at compile/validation time):

Note that org.eclipse.e4.ui.examples.job is not activated (misses green overlay triandle on the icon).

OSGI console ss shows it as 150 STARTING org.eclipse.e4.ui.examples.job_0.5.0.qualifier and diag says

diag org.eclipse.e4.ui.examples.job
org.eclipse.e4.ui.examples.job [150]
  No resolution report for the bundle.

So PDE / runtime seem to have troubles to start or actvate that bundle automatically. Do you have some bundle which needs & activates org.eclipse.e4.ui.examples.job in your target platform?

[merks]

Oops, sorry I did rebase to the wrong PR. Sorry, sorry.

[fedejeanne]

Do you have some bundle which needs & activates org.eclipse.e4.ui.examples.job in your target platform?

Not that I can see:

... also, I only use the normal TP that is delivered for the Committers IDE (I didn't change anything):

[fedejeanne]

This is what I see in my launched application:

I seem to have a few less plugins than you in the Plug-in Registry (482 instead of 487) but I see a lot more matches with the word examples in the Target Platform State view. FTR I have 860 Plug-Ins in the TP (Window > Preferences > Plug-In Development > Target Platform) and I also see org.eclipse.e4.ui.examples.job v0.5.0 in there. Just a thought: maybe it's necessary to bump versions for these kind of changes? I noticed we haven't done that in a while...

... which probably means that the TP already thinks it has the newest version and some old cached state is being used? You could quickly check if you see the button Robin and I introduced in the Job Factory view in #4121

... if you don't, I could bet you have some cached version of org.eclipse.e4.ui.examples.job and bumping the version of the Plug-In in the WS (and in this PR) would fix it.

[fedejeanne]

I need to revisit the tests. Drafting PR.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

bundles/org.eclipse.text.quicksearch/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 11a218ab86471d244919df0b5a666d69f4d2439b Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Thu, 6 Aug 2026 11:05:23 +0000
Subject: [PATCH] Version bump(s) for 4.41 stream


diff --git a/bundles/org.eclipse.text.quicksearch/META-INF/MANIFEST.MF b/bundles/org.eclipse.text.quicksearch/META-INF/MANIFEST.MF
index c81a682902..9bbeb36695 100644
--- a/bundles/org.eclipse.text.quicksearch/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.text.quicksearch/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.text.quicksearch;singleton:=true
-Bundle-Version: 1.3.500.qualifier
+Bundle-Version: 1.3.600.qualifier
 Bundle-Activator: org.eclipse.text.quicksearch.internal.ui.QuickSearchActivator
 Require-Bundle: org.eclipse.ui;bundle-version="[3.113.0,4.0.0)",
  org.eclipse.core.resources;bundle-version="[3.13.0,4.0.0)",
-- 
2.54.0

Further information are available in Common Build Issues - Missing version increments.

[fedejeanne]

• Rewrote the tests so that fork==false cases are meaningful.

• The test names encode all 6 assertDialogShown params: fork, cancelable, runInBackground, callFromUIThread, pumpUiEventsWhileRunning, expected outcome.

• blockingUiThread vs pumpingUiEventsWhileRunning in the test names: the former means the UI freezes i.e. no chance for a dialog to appear while the latter keeps the UI responsive i.e. the dialog gets a real chance to appear.

• callFromNonUIThread in the test names: IProgressService#run always throws SWTException(ERROR_THREAD_INVALID_ACCESS) when calling from outside the UI thread, regardless of fork. There are only 2 tests, not a full matrix, since the failure happens before any params are read.

• There was another hidden bug that the previous version of this PR didn't fix namely if (!fork || !cancelable) then the 800ms delay of org.eclipse.ui.internal.progress.ProgressManager.getLongOperationTime() wasn't honored. This PR now fixes that too and the JavaDocs in the tests mention that bug too.