Do not send xdotool key commands to Chrome window

[phardy]

TLDR: This pull request fixes closing the Chrome window in the plugin on Linux, allowing remotes to close the browser window without pulling out a keyboard or doing any other finagling.

Having xdotool send keystrokes directly to the Chrome window bypasses the window manager, which means the alt-f4 shortcut won't be received by it, and the window doesn't close. So I stopped searching for the Chrome window. This gives the WM a chance to intercept alt-f4 and do its window closing thing, and all other keystrokes will be passed through to the foreground window (hopefully Chrome).

I've tested this on a Debian Unstable machine with the following environments:

• GNOME 3.14
• fluxbox 1.3.5
• openbox 3.5.2

All behaved as expected, with no change to netflix shortcuts (I tested volume control and forward/backward seeking), and hitting the back button on my yatse remote caused the browser to exit and the plugin cleaned up gracefully.

Bonus change, moving the debug log above the sys.exit(), so we still get logging when the script exits.

If this approach is deemed too risky, I'd be willing to test replacing it with Ctrl-Shift-Q, which is the Chrome shortcut for exiting the application, according to https://support.google.com/chrome/answer/157179?hl=en

[andrewleech]

Thanks for the pr. I wont add this in the release I'm about to push until I get a chance to review it as this can be a touchy area of the code... with the various different ways input methods and handled I've found any change usually breaks for someone with a different input method (keyboard vs lirc vs network etc). My main fear is if the input focus gets a little out of whack and the keystroke gets sent to kodi instead and closes that rather than chrome. I think there's some people who're using this without a window manager as well (on kodibuntu and similar where it boots straight to kodi), which this would probably break. Perhaps it'll need a setting to enable/disable sending command to chrome directly.

[phardy]

No worries. :)

Sending things to the wrong window is a valid concern. But I wasn't too worried about environments without a window manager because of several posts in the release forum thread discussing problems with Chrome's kiosk mode only running in half the screen. That was a problem I had too, switched from running kodi-session on its own to openbox + kodi just to get this plugin running properly.

If the ctrl-shift-q shortcut works that seems like a much less invasive way to do it.

[projectgus]

Hi phardy,

I'm the one who sent the PR a few weeks ago to change xdotool tio target chrome specifically. Before the change I had the situation andrew describes where the keypresses would sometimes land on kodi - in some cases it'd close Kodi entirely because the "close" hit it instead of Chrome. Sorry it broke things for you! I run openbox and it seems like it's immune.

The other nice thing about having xdotool search for the Chrome window is that it provides an error result if Chrome has gone away unexpectedly, so the plugin can tell that it should stop.

I think Ctrl-Shift-Q sounds like a good solution. It seems to work fine on my setup, I sent it as a new PR #52.

[phardy]

Cool. I hadn't had a chance to test alternatives properly yet, glad there's a solution in place. Thanks for that projectgus. :)