[DEFECT] Project Explorer double-click and Enter do not open files while the PlantUML preview view holds focus

[tviegut]

Describe the defect:

While editing a profile in CIMTool with the real-time PlantUML preview view (CurrentProfilePlantUmlSvgView) open and visible alongside the profile editor, opening another file by double-clicking it in the "Project Explorer" intermittently fails to open the file: the target file is selected (it highlights blue) but no editor opens, and no error is reported. The failure occurs only while a profile editor is the active part and the preview view is open; it is not specific to *.owl files (any file type fails to open under the same conditions). Closing the preview view, or moving focus to any other editor (including a non-profile editor such as an XML editor), restores normal double-click behavior.

The behavior is non-deterministic: the same double-click sometimes opens the file and sometimes does not, depending on timing. No entry is written to the Eclipse "Error Log" when the open fails, indicating this is a focus-state problem rather than a thrown exception.

The root cause is a known platform-level defect in the Eclipse SWT Edge/WebView2 Browser backend. The preview view hosts an SWT Browser; on Windows this resolves to the Edge/WebView2 backend (required for the view's DOMParser/svg-pan-zoom-based interactive rendering, which the legacy Internet Explorer backend cannot run). When the preview renders, the native WebView2 control acquires input focus asynchronously. Per Eclipse SWT issue #1848 ("Edge: Focus jumps back to browser control when trying to leave"), WebView2 then re-asserts focus to the browser via an obsolete asynchronous handleGotFocus callback after focus has already moved elsewhere. While the browser holds native focus, the first click of a Project Explorer double-click is consumed transferring focus away from the browser, degrading the gesture to two single clicks — selection without an open.

Because the focus re-grab occurs inside SWT's own Edge implementation, application-level focus restoration in CIMTool cannot reliably prevent it (this was confirmed empirically — multiple application-side focus guards failed to win the race against SWT's internal re-grab).

CIMTool release:

CIMTool 2.3.0 — the release that introduces the PlantUML Real-Time Profile Preview view.

CIM Schema Version:

Not applicable. The defect is in the workbench/preview UI and is independent of the profiling schema.

To Reproduce:

1. Open a profile (*.owl) in the "Profile Editor".
2. Open the "Current Profile PlantUML SVG" preview view so it is visible alongside the editor.
3. Make the profile editor the active part.
4. In the "Project Explorer", double-click a different file (any type) to open it.
5. Observe that, intermittently, the target file is selected (it highlights) but no editor opens, and nothing is written to the "Error Log".

Expected behavior

Double-clicking a file in the "Project Explorer" opens it in an editor — the same behavior observed when the preview view is closed or when a non-browser editor holds focus.

Additional context

• Root cause is Eclipse SWT issue #1848, "Edge: Focus jumps back to browser control when trying to leave" (Windows, Edge/WebView2 backend), tracked under the SWT Edge roadmap issue #1466. The SWT Edge implementation re-asserts focus to the browser on an obsolete asynchronous handleGotFocus notification, which is what leaves the workbench focus state inconsistent and breaks the navigator open.
• Environment: Windows; Eclipse 2023-06 (4.28); JDK 20 — the pinned CIMTool development/build platform.
• Application-level focus restoration cannot reliably prevent the re-grab, because it is performed by SWT itself. The effect (the failed open) can nonetheless be worked around at the application level by intercepting the raw input events and rerouting the open beneath SWT's gesture synthesis (see Interim mitigation adopted below) — a stopgap, not a fix. Resolving the underlying defect requires upgrading the underlying Eclipse/SWT platform to a version in which the Edge/WebView2 focus handling is corrected. SWT #1848 is classified "Minor" in the Edge roadmap; the Edge backend became the default browser on Windows in Eclipse 4.35 (2025-03). The exact release that resolves #1848 should be verified during platform-upgrade scoping (candidate target: Eclipse 4.35 / 2025-03 or later).
• This platform upgrade aligns with the migration already required to adopt TM4E 0.17.2 (which requires the Java 21 execution-environment baseline introduced around Eclipse 4.32–4.35). A single Eclipse/SWT platform upgrade can therefore resolve this defect together with the TM4E syntax-highlighting enhancement, allowing both to be targeted at one release.
• Interim mitigation adopted (CIMTool 2.3.0). A temporary, platform-scoped workaround ships in this release. An org.eclipse.ui.startup contribution (au.com.langdale.cimtoole.interceptors.ProjectExplorerDoubleClickInterceptor) attaches raw SWT.MouseDown and SWT.KeyDown listeners to the "Project Explorer" tree, reconstructs the double-click and handles Enter / keypad-Enter from the primitive input events — which still arrive, since selection continues to work — and routes the open through IDE.openEditor(...), the same path used by the unaffected "Open With" action. It operates beneath SWT's gesture synthesis, which is why it succeeds where application-level focus restoration cannot. Verified in the failing focus state for both gestures and across file types; folder/container expansion, twistie single-click, and multi-selection are unaffected (the interceptor acts only on a reconstructed double-click of a single file node and declines non-file nodes).
  • This mitigation is deliberately temporary and scoped to the pinned Eclipse 2023-06 (4.28) platform. It resolves the tree by reflection (getCommonViewer().getTree()), which is acceptable only because it is bound to this exact platform. It must be removed as part of the platform upgrade that resolves SWT #1848. That upgrade — not this workaround — is the long-term fix.
  • The sanctioned CommonActionProvider open hook was prototyped and rejected: in the failing focus state its ICommonActionConstants.OPEN handler does not fire at all (the framework's open event rides the same un-formed double-click gesture), so it cannot mitigate the defect. The raw-event interceptor was adopted precisely because it operates below that level.
• Other options considered but not adopted:
  • Reduce render frequency — render the preview only when its view is the active/visible part, rather than on background profile-editor activation. This reduces how often the browser acquires focus during navigation but is not guaranteed to eliminate the defect, because #1848 re-asserts focus to the browser specifically when focus leaves it.
  • Defer the preview view — withhold the real-time preview from the release until the platform upgrade is complete. Not adopted; the interim mitigation above keeps the feature shippable in 2.3.0.
• Related: Eclipse SWT #1848 and #1466; the CIMTool TM4E syntax-highlighting enhancement (shares the platform-upgrade dependency).