Key state is misreported for ~1s when going from unity's editor UI to focusing the game view

Unity Engine
, , ,
1

I’m working on a project that’s effectively recreating scene view navigation, where you hold alt and click+drag LMB to orbit a camera

But when unity’s editor UI is in focus, and I start holding alt, and then click and drag in the game view to orbit my camera - the alt modifier key doesn’t register as held, until after about one second.

I suspect this is unity’s editor UI eating the key down event, and then once I click and drag in the game view, it doesn’t pick up on the fact that the alt key is held, until after the key repeat delay.

Basically the steps are:

  • press play
  • click anything in unity’s UI (console, asset, whatever)
  • hold down alt, and then immediately after…
  • …click and drag LMB in the game view
  • for about one second, the Alt key reports as not held (all of this before releasing either LMB or Alt)

It seems to happen to every key, not just alt

I tried all of these detection methods, none of which work correctly while using the new input system:

void EvtMouseMove( MouseMoveEvent evt ) {
    Debug.Log( "Input system: " + actionRef.action.IsPressed() );
    Debug.Log( "Input s. raw: " + Keyboard.current.leftAltKey.ReadUnprocessedValue() );
    Debug.Log( "Legacy Input: " + Input.GetKey( KeyCode.LeftAlt ) );
    Debug.Log( "UITK modifr.: " + ( ( evt.modifiers & EventModifiers.Alt ) != 0 ) );
}

Does anyone know of a workaround for this? some way to force unity to let go or refresh the UI events immediately on focus?

(In the meantime I’ve reported a bug, case IN-88227)

2

Just tried this, which, also didn’t fix it

void OnApplicationFocus( bool hasFocus ) {
    foreach( InputDevice device in InputSystem.devices )
        InputSystem.ResetDevice( device, true );
}
3

Hi, I wanted to call out that the input team have seen this issue and are investigating the topic.
Your assumption about the UI consuming the event before you get back to the game view sounds likely.
From the description it sounds like you are trying a new flow that may not be well supported, rather than reporting a regression in functionality

4

potentially! I’d probably consider it a regression though, since this problem doesn’t happen when using the legacy input system on its own - it’s only a problem in projects using the new input system, as far as I know

5

Hi,

The Game view in the editor that supports playmode has some interesting challenges to solve - one of which is providing the illusion that it behaves just like a standalone player would. This works best when it has focus.

When another Editor element has focus (Inspector / Console &c.) and playmode is active Unity has the problem of how to deal with input - and the problem here is that the initial Alt button down event went to the editor element that had focus when it was pressed.

A standalone Windows application will not see the WM_KEYDOWN message if you press the Alt key when the application does not have focus and then subsequently click in the application window.

Behind the scenes within the editor there are conceptually two streams - one for the Editor and one for the “Player” running in the playmode Game view.

There are settings to adjust some of this.

If you apply these:

  1. Set Player Settings / Resolution and Presentation / Run In Background to: ON
  2. Set Input System Package / Settings / Background Behavior to: Ignore Focus
  3. Set Input System Package / Settings / Play Mode Input Behavior to: All Device Input Always Goes To Game View

This leads to these two working as you expect:

  • Keyboard.current.leftAltKey.ReadUnprocessedValue()
  • action.action.IsPressed()

They will reflect the state of the Alt key even when the Game view does not have focus.

However these settings would also affect a standalone player too of course.

6

ah heck yeah this works! thank you so much for the workaround! <3