Terminal:input may be locked on switching workspaces using Alt-Fn shortcut

[siarzhuk]

To reproduce the problem:

• open terminal on the workspace 1;
• start building Haiku;
• use Alt-F2 to switch to workspace 2;
• go back to workspace 1 using Alt-F1;
• terminal input is locked until you press Alt again, and links are colored blue under the mouse pointer without pressing Alt.

This issue looks like related to last hot-links feature addition.

[bonefish]

Will have a closer look. Currently it is checked whether the hyperlink mode needs to be left whenever the window activation or the pressed modifiers change. My suspicion is that in this case the terminal view simply doesn't get a B_MODIFIERS_CHANGED message when the Command key is released.

I've also run into another curious situation where the hyperlink mode is locked: When switching between terminal tabs with Shift+Left/Right one sometimes gets stuck in the hyperlink mode. For this case an explanation escapes me, though, since the mode is only ever entered when B_COMMAND_KEY is pressed.

[bonefish]

At least in qemu I cannot reproduce the issue using the given steps. I left out the "start building Haiku" one. Is that relevant? I tried some CPU-consuming alternative, but to no avail. I also tried both FFM and click to focus mode, each in combination with different mouse positioning (over/out of the window) when switching back. No dice.

FWIW I also failed to reproduce the other issue I mentioned. Come to think of it I often see USB keyboard related errors/messages in my syslog. So in my case it may just be an erroneous modifier event being sent by the driver/input add-on.

Please try whether the attached patch fixes the issue for you and/or introduces new problems.

[siarzhuk]

Replying to bonefish:

At least in qemu I cannot reproduce the issue using the given steps. I left out the "start building Haiku" one. Is that relevant?

No it is not relevant - just switching workspaces has left the terminal locked. BTW, I have KeymapSwitcher installed - it's filter addon may be the "catalyst" for this issue.

Please try whether the attached patch fixes the issue for you and/or introduces new problems.

I have applied your patch and this issue has gone way. I'll check it for some time and let you know about results. Thank you!

[siarzhuk]

The origin of problem is Keymap Switcher. It is reproduced in the following situation: on the first workspace I have opened window with active Russian keymap. On the second workspace the Terminal window with German (default) keymap. When switching ws1 <-> ws2 the keymap switcher reloads the current keymap because of change the active window keymap. Looks like this is the place where B_MODIFIERS_CHANGED is eaten. But your patch workarounds this behaviour.

Just for information: on non-patched system visual effect of this lock is blue-highlighted path in the Terminal window under the mouse pointer. On the patched system the same highlighting effect is still observed, but after any key was hit it goes away.

[bonefish]

Replying to siarzhuk:

The origin of problem is Keymap Switcher. It is reproduced in the following situation: on the first workspace I have opened window with active Russian keymap. On the second workspace the Terminal window with German (default) keymap. When switching ws1 <-> ws2 the keymap switcher reloads the current keymap because of change the active window keymap. Looks like this is the place where B_MODIFIERS_CHANGED is eaten. But your patch workarounds this behaviour.

It would be much better to fix Keymap Switcher, though, since other applications could be affected as well.

Just for information: on non-patched system visual effect of this lock is blue-highlighted path in the Terminal window under the mouse pointer. On the patched system the same highlighting effect is still observed, but after any key was hit it goes away.

That is expected. Moving the mouse should help as well. The modifier check is done whenever a user event is received. TermView doesn't override KeyUp(), so in that case a check doesn't happen. Maybe adding it would help. OTOH the event might get lost just like the B_MODIFIERS_CHANGED.

[siarzhuk]

Replying to bonefish:

It would be much better to fix Keymap Switcher, though, since other applications could be affected as well.

This on-the-fly keymap reload is the key technique of the KyemapSwitcher. It is performed in the change team notification handler in case keymap id of the new team was changed. I'm afraid the easier way to fix the Keymap Switcher will be to replace it with native keymap switching solution in the app server. May be we can apply this patch temporarily and left this ticket opened and referenced to #1449 as marker for reverting the workaround after #1449 will be fixed?

[siarzhuk]

Workarounded in hrev45846. Should we close it as fixed or wait for revert until fixing #1449 throws the Keymap Switcher away?

[bonefish]

Closing as fixed. It also fixes/works around my problem I mentioned in comment:3, so I wouldn't just revert the change after #1449 has been fixed.