ContentAssistProcessor no longer activated when CTRL key is pressed

[ptziegler]

Let's make sure issue is not already fixed in latest builds first.

• [x] I verified I can reproduce this issue against latest Integration Build of Eclipse SDK

Steps to reproduce

• Create a custom source viewer with a default ContentAssist.
• Register a custom ContentAssistProcessor that is automatically activated when pressing space.
• Activate the processor by pressing CTRL+Space

I expected: The processor to be activated

But got: The processor remains inactive

Tested under this environment:

• Windows 11
• Eclipse 2024-12

Workaround

ContentAssistant assistant = new ContentAssistant() {
    @Override
    protected AutoAssistListener createAutoAssistListener() {
        return new AutoAssistListener() {
            @Override
            public void keyPressed(KeyEvent e) {
                if (e.stateMask == SWT.CONTROL) {
                    e.stateMask = 0;
                }
                super.keyPressed(e);
            }
        };
    }
};

Community

• [x] I understand reporting an issue to this OSS project does not mandate anyone to fix it. Other contributors may consider the issue, or not, at their own convenience. The most efficient way to get it fixed is that I fix it myself and contribute it back as a good quality patch to the project.

This is a result of https://github.com/eclipse-platform/eclipse.platform.ui/pull/1556 in an attempt to fix https://github.com/eclipse-platform/eclipse.platform.ui/issues/891. As part of this change, any events where the CTRL key is pressed will no longer activate the content processor.

In hindsight, I wonder if it would've been a better approach to create a subclass for the AutoAssistListeners and use it wherever state masks are undesirable.

[ptziegler]

As far as I understand the initial bug, the issue was reported for the Java editor. My proposal is to push this restriction to the JavaSourceViewerConfiguration by subclassing the ContentAssistant there and then reverting aa42db11608ae15948c45836be3bb4a0a6d3827d.

[ptziegler]

I don't think it's worth the trouble trying to fix this across different projects, so we'll just continue with the workaround. The fix is in the linked PRs and 100% done, in case anyone is still interested.