Is this a regression? If yes, in which version?

Note: there aren't many contributors with Mac access, so if you can reproduce & fix, patch is welcome.

Is this a regression? If yes, in which version?

Regression definitely, but at least 4 releases, today this just driving me crazy :P (I saw this on JDT, PDT and GenericEditor)

Note: there aren't many contributors with Mac access, so if you can reproduce & fix, patch is welcome.

First I have to find correct UI classes

In general I have a lot of small but sometimes annoying UI issues on MacOS, I'll see what I can do ;)

First I have to find correct UI classes

CompareEditor, StructureDiffViewer, DiffTreeViewer

Cool to see someone else using the dark theme @zulus Thanks for looking into this issue.

CompareEditor, StructureDiffViewer, DiffTreeViewer

Look like problem is earlier, on SWT Tree:

When works correctly I see SWT events:

• down
• select
• up

Is broken when eclipse receive

• down
• up
• mouse exit (why???)
• up (duplicated event)
• select

I have no idea why :( Display sends exit event because Display.findControl return null (this is checked inside applicationSendTrackingEvent)

@Phillipus maybe you can manage to give some hints here

@Phillipus maybe you can manage to give some hints here

I can't reproduce this.

I'm on macOS Ventura M1 Silicon with hi-dpi screen. Eclipse 4.28, Java 17.

Maybe I'm missing a step to reproduce this?

Update. I tried on my MacBook Air, Intel, macOS Ventura with track pad and I'm seeing this too. Not sure if this is an Intel vs Silicon thing or a mouse vs trackpad thing. Resizing the dialog window forces proper display.

Edit: Can now see this behaviour on Mac M1 with mouse.

@zulus It would help if you could provide more details for macOS version, Mac version, Eclipse version, Java version etc...

Java 17 Temurin, Ventura 13.5.2 (m1 max), Eclipse 2023-09, I see this with magic mouse and trackpad

Java 17 Temurin, Ventura 13.5.2 (m1 max), Eclipse 2023-09, I see this with magic mouse and trackpad

Thanks. Since my previous messages I'm also able to reproduce this with mouse or trackpad on Intel and Mac Silicon.

I think I understand what happens:

1. Mouse down (if don't up immediately you will always see this behaviour until up), it firesSelectionEvent
2. Select has been sent (if you keep mouse clicked will see same as on screen)
3. Mouse up (normally during this layout is relcalculated (event open), but if it hapen before select finish his job "up" event isn't able to detect view, because durin changing page, focus is updated, so "mouse select"/open have invalid data

Its due busy indicator, starts always during feedInput when documents are created (it makes user interface inactive for a moment, so all layouts are suspended and wrongly calculated). If you move feedInput after showPage, UI looks a little bit better but it's still unusable.

I implemented workaround on LTK level: eclipse-jdt/eclipse.jdt.ui#844

I implemented workaround on LTK level: eclipse-jdt/eclipse.jdt.ui#844

I believe this is not the right place to fix such (OS specific) issues. I would assume this is something on lower level, like SWT or Platform UI.

To be honest, platform issue is suspended layout. But in general, IChangePreviewViewers aren't correctly created, their merge viewers aren't connected to ICompareContainer, so in moment when DocumentMergeViewer prepare ranges during "doDiff" extra popup is created

OK, so now platform lvl fix eclipse-platform/eclipse.platform#732 ;)

PR merged

Fix was reverted via eclipse-platform/eclipse.platform#869 , see eclipse-platform/eclipse.platform#868.

@tobiasmelcher:
Does your PR eclipse-platform/eclipse.platform#1625 fix this UI glitch?

eclipse-platform/eclipse.platform#1625

No, org.eclipse.ltk.internal.ui.refactoring.PreviewWizardPage needs to be modified the similar way like in #1625 . Method showPreview cannot be called on selectionChanged but needs to be delayed to onMouseUp. I can do the change if you want.