CrossOver Support - Community Forums

Important Information These are community forums and not official technical support. If you need official support: Contact Us

CrossOver Mac
Discussion about CrossOver Mac

The following comments are owned by whoever posted them. We are not responsible for them in any way.

Back to Threads Reply to Thread

Keyboard input does not work after task switch to Crossover application

Hi there,

I recently upgraded to Crossover 20, and some behaviour changed in this process.

Given a Windows program I run with Crossover (macOS 10.15.7) that does not have focus, and I task switch using cmd-tab to the Windows application; input from the keyboard does not reach the application; until the application captures my mouse input.
Same behaviour occurs when I click with the mouse pointer on the Applications macOS window tab (the one with the red/yellow/green buttons). So I have to explicitly click inside the Crossover window before I can input using the keyboard.

Did anyone else notice this? Is this a intentional change or regression?

Kind regards,
Wietze

Hi,

Could you be a bit more specific? Windows applications vary greatly in how they handle focus loss, and thus they run differently on CrossOver. What specific applications are you seeing this behavior with?

Thanks,
Anna

wietze spijkerman wrote:

Hi there,

I recently upgraded to Crossover 20, and some behaviour changed in
this process.

Given a Windows program I run with Crossover (macOS 10.15.7) that
does not have focus, and I task switch using cmd-tab to the Windows
application; input from the keyboard does not reach the application;
until the application captures my mouse input.
Same behaviour occurs when I click with the mouse pointer on the
Applications macOS window tab (the one with the red/yellow/green
buttons). So I have to explicitly click inside the Crossover window
before I can input using the keyboard.

Did anyone else notice this? Is this a intentional change or
regression?

Kind regards,
Wietze

I am experiencing something that may well be the same issue. I generally do searches in a browser running in one desktop - I get the same results whether I use Safari or Firefox - and having decided the values I wish to use from the search result, I then switch desktops - Spaces - to a fullsceen application (RootsMagic 7) - running under Crossover 20 and attempt to type into the top window, which has become the active window. This has always worked in the past with the input going where the cursor was last positioned in that window, but now I have to position the cursor where the input is to go before it will appear. Otherwise the typing is just lost. It is as though the cursor positioning is lost once one switches out of that desktop.

The application I am experiencing this with is Steem 3.2 (Atari ST(E) Emulator).

This behaviour changed when moving from 19.02 to 20 crossover version.

Before, using 19.02, I could CMD-TAB and task switch to the application and the Steem Emulator would capture keypresses.
Using 20, after CMD-TAB task switch to the application, I have to click inside the window area, before Steem captures keypresses.

Although this may be related to the application, this surely is related to changes made in recent release. Ever since I have been a Crossover customer, this behaviour has never changed, until now.

Hi all,

I was able to reproduce this issue on macOS 10.15.7, and I filed a bug so a developer can take a look. Thanks for the reports!

Meredith

Having the same "lost keyboard input" issue.
@Meredith thank you for submitting a bug from this forum thread. hopefully it gets attention and developers start working on it.
I've created support ticket 1273272 ten days ago, and though it was assigned there are no updates posted yet :(

I am not able to access that ticket referenced in the post above. I am very interested in following the resolvement of the issue.

How can I track this bug report?

Hi,

You can file your own ticket and ask to be added to Bug 18310 :)

Thanks,
Anna

It tells me the page I try to access is locked ; access denied.

Resolved with below update
20.0.1 CrossOver - November 10, 2020
Applications should again regain focus after a command-tab.

1

I had a similar issue with some Windows games, albeit they would completely refuse to accept the input (both keyboard and mouse) even if the mouse cursor was rendered in game properly.
The trick that worked for me was to launch Task Manager, find the app / game in the list, and click on Switch To button.

This just started happening to me with the upgrade to 21. The windows app looses keyboard and mouse input when switching windows. It's hard to reproduce as it also happens when using modal dialogs as well. Oddly, the scroll wheel continues to function normally.
Any ideas to test would be appreciated.

Hi Samuel,

Which applications are working better with focus loss on 20 than 21?

Best,
Meredith

Hi Meredith,
I've narrowed it down to a problem with SierraChart. I'll put the steps here to reproduce it if someone else has the same problem.

  1. Linked chart in Chart -> Chart settings -> Advanced Settings 2 -> Copy Chart Drawings From Chart #'s: {Your chart to link #} ; Click Ok
  2. Click Chart Val button, then click on the chart to show that it's work.
  3. Click on the Title Bar and move the window a bit
  4. Click on the chart and notice that you can't move the value lines
  5. Minimize the window with the yellow Mac minimize
  6. Restore the window
  7. You can now move the chart value line
  8. Clear the box in step 1 so no charts are linked, and it all works.

I'll put in a ticket with SierraChart.
Thanks,
-Sam

1 to 14 of 14

Please Note: This Forum is for non-application specific questions relating to installation/configuration of CrossOver. All application-specific posts to this Forum will be moved to their appropriate Compatibility Center Forum.

CrossOver Forums: the place to discuss running Windows applications on Mac and Linux

CodeWeavers or its third-party tools process personal data (e.g. browsing data or IP addresses) and use cookies or other identifiers, which are necessary for its functioning and required to achieve the purposes illustrated in our Privacy Policy. You accept the use of cookies or other identifiers by clicking the Acknowledge button.
Please Wait...
eyJjb3VudHJ5IjoiVVMiLCJsYW5nIjoiZW4iLCJjYXJ0IjowLCJ0enMiOi01LCJjZG4iOiJodHRwczpcL1wvbWVkaWEuY29kZXdlYXZlcnMuY29tXC9wdWJcL2Nyb3Nzb3Zlclwvd2Vic2l0ZSIsImNkbnRzIjoxNzA4NjEzODE4LCJjc3JmX3Rva2VuIjoidVhUUDNNSm12ZHRDVWdtMyIsImdkcHIiOjB9