Synergy-core: macOS: Back button on mouse doesn't work

[Celant]

Operating Systems

Server: Windows 10 64-bit
Client 1: macOS 10.10
Client 2: Linux Ubuntu 16.04

Synergy Version

1.8.4

Steps to reproduce bug

1. Connect clients to Windows server
2. Navigate to a page in a browser
3. Click the back button on the mouse

Expected: Browser navigates back a page
Actual: No button press occurred.

[Zolomon]

Same for Linux client.

[minostauros]

Any updates?

[minostauros]

I believe this is a crucial feature but seems like no one is interested :(

[apedevmicrosoft]

I have the same issue with Linux client and 1.8.8 as server.

[yupi2]

@apedevmicrosoft I added forward/back buttons to my fork but you'll have to run it from source and I haven't set up packages

[dragon788]

I found a fascinating "feature" while trying to debug this (yet again) on a recent install of Synergy 1.1x on Ubuntu as host with a macOS client. It appears that Synergy does some mutation/overriding of the mouse keypresses internally, and between the wizard Hotkeys window that incorrectly sees BOTH the forward/back keys as mouse(4), and the DEBUG2 and DEBUG1 log levels that are showing different mouse keys detected when pressing forward and back (mouse(9) and mouse(8) in DEBUG2, mouse(7) and mouse(6) in DEBUG1) it can be fun to figure out what is actually happening.

TLDR;

Bad config:

    mousebutton(4) = ;keystroke(Meta+[,MacBook-Pro-ONE.local:MacBook-Pro-TWO.local)
    mousebutton(3) = ;keystroke(Meta+],MacBook-Pro-ONE.local:MacBook-Pro-TWO.local)

Good config:

    mousebutton(6) = ;keystroke(Meta+[,MacBook-Pro-ONE.local:MacBook-Pro-TWO.local)
    mousebutton(7) = ;keystroke(Meta+],MacBook-Pro-ONE.local:MacBook-Pro-TWO.local)

All credit for this workaround goes to AJDaws in the forums.
https://members.symless.com/forums/topic/5303-do-back-and-forward-mouse-buttons-work-for-people/?do=findComment&comment=28487

The trick to having the remapping work appears to be to adding the recommending mapping lines to a custom synergy.conf that you can initially create with "Save Configuration As" if you've used the wizard, and then you will need to fix it up and save your changes because the wizard is goofy (see above) and then tell Synergy to "Use existing configuration" and browse to the path of the file you just exported. You can create this config anywhere, but if you create it at ~/.synergy.conf supposedly just launching synergys (the server) will automatically read it (instead of needing to run with synergys -c ~/path/to/config). Despite the weird quirk noted above, it doesn't matter which log level you use once you've supplied the custom config, but you can use Settings to change to DEBUG1 and Apply to ensure the mappings are seen and passed correctly and then switch it back to INFO and Apply again.

Sadly the GUI itself does NOT behave this way, it looks at ~/.config/Synergy/Synergy.conf for its config and if you were thinking about modding that directly, it is gross, but it also auto-writes itself when the Synergy GUI is launched or quit, so make sure you've quit the GUI and it isn't running anymore before you make any changes.

If your config shows * after the comma that means ALL clients. My only client "screens" currently are macOS, but I checked the option to limit it to specific clients and it appears to be a : separated list of client names as shown below. I'm not really sure _what_ the ; before the keystroke() means as it seems to work with or without it. The main reason I'm defining the Macbooks explicitly is on the off chance that I may add a Windows or Linux system to the mix, I don't want to remap the mouse buttons to the same thing there, but given some of the weirdness I've encountered (noted below) I'm not sure if this will actually matter.

WARNING

It would seem you can configure multiple different actions for a single mouse button or keypress based on the client name (ie keystroke(WWWBack) for Windows/Linux and keystroke(Meta+[) for MacOS) because the wizard allows you to do this, but "the cake is a lie!". If you apply more than one mapping to a keystroke in your config, the LAST definition wins. I'd hoped it would save the mappings as one per host and check which host had focus, but it must do it another way.

Apparently mouse buttons are also handled slightly differently than direct keystrokes. If you configure a keystroke mapping specifically for remote screens, it will likely break it for the local host's "screen", as you essentially make it a dead keystroke that always gets directed to the remote, but mouse buttons are maybe smart enough to know whether they are local (skip the mapping) or remote (apply the mapping).

I was trying to map Ctrl+C/Ctrl+V to Meta+C/Meta+V for macOS but no matter if I applied it to * or MacBook-Pro-ONE:MacBook-Pro-TWO any time I hit Ctrl+C intending to copy from LinuxHost it was copying on MacBook-Pro-ONE (I could see the Edit menu highlighting as it does when Cmd+C/Cmd+V are hit) and the DEBUG1 log output confirmed this.

I finally figured out the trick to this is to just remap Ctrl or Alt to Meta or Super per screen per https://github.com/symless/synergy-core/wiki/Text-Config#screen_options

I eventually discovered the difference between keystroke/keyboard (triggers against all screens), and mousebutton (ignores primary screen and only affects secondary screens). See the keystroke(key) = actions and mousebutton(button) = actions notes at the bottom of this section.
https://github.com/symless/synergy-core/wiki/Text-Config#list-of-options

BONUS GORE
If you want to see the gnarly hotkey syntax output by the wizard, here's a taste.
268435456 is apparently magic for Meta and 91 is [ while 93 is ], the latter two almost make sense if you search for "ASCII left bracket", though I find it odd the character index used is of printable characters rather than HID input scan codes.

hotkeys\1\actions\1\activeOnRelease=true
hotkeys\1\actions\1\hasScreens=false
hotkeys\1\actions\1\keys\1\key=268435456
hotkeys\1\actions\1\keys\2\key=91
hotkeys\1\actions\1\keys\size=2
hotkeys\1\actions\1\lockCursorToScreen=0
hotkeys\1\actions\1\switchInDirection=0
hotkeys\1\actions\1\switchScreenName=LinuxHost
hotkeys\1\actions\1\type=2
hotkeys\1\actions\1\typeScreenNames\1\typeScreenName=MacBook-Pro-ONE.local
hotkeys\1\actions\1\typeScreenNames\2\typeScreenName=MacBook-Pro-TWO.local
hotkeys\1\actions\1\typeScreenNames\size=2
hotkeys\1\actions\size=1
hotkeys\1\keys\1\key=7
hotkeys\1\keys\size=1
hotkeys\2\actions\1\activeOnRelease=true
hotkeys\2\actions\1\hasScreens=false
hotkeys\2\actions\1\keys\1\key=268435456
hotkeys\2\actions\1\keys\2\key=93
hotkeys\2\actions\1\keys\size=2
hotkeys\2\actions\1\lockCursorToScreen=0
hotkeys\2\actions\1\switchInDirection=0
hotkeys\2\actions\1\switchScreenName=LinuxHost
hotkeys\2\actions\1\type=2
hotkeys\2\actions\1\typeScreenNames\1\typeScreenName=MacBook-Pro-ONE.local
hotkeys\2\actions\1\typeScreenNames\2\typeScreenName=MacBook-Pro-TWO.local
hotkeys\2\actions\1\typeScreenNames\size=2
hotkeys\2\actions\size=1
hotkeys\2\keys\1\key=6
hotkeys\2\keys\size=1
hotkeys\3\actions\1\activeOnRelease=true
hotkeys\3\actions\1\hasScreens=true
hotkeys\3\actions\1\keys\1\key=268435456
hotkeys\3\actions\1\keys\2\key=86
hotkeys\3\actions\1\keys\size=2
hotkeys\3\actions\1\lockCursorToScreen=0
hotkeys\3\actions\1\switchInDirection=0
hotkeys\3\actions\1\switchScreenName=LinuxHost
hotkeys\3\actions\1\type=2
hotkeys\3\actions\1\typeScreenNames\1\typeScreenName=MacBook-Pro-ONE.local
hotkeys\3\actions\1\typeScreenNames\2\typeScreenName=MacBook-Pro-TWO.local
hotkeys\3\actions\1\typeScreenNames\size=2
hotkeys\3\actions\2\activeOnRelease=true
hotkeys\3\actions\2\hasScreens=true
hotkeys\3\actions\2\keys\1\key=67108864
hotkeys\3\actions\2\keys\2\key=86
hotkeys\3\actions\2\keys\size=2
hotkeys\3\actions\2\lockCursorToScreen=0
hotkeys\3\actions\2\switchInDirection=0
hotkeys\3\actions\2\switchScreenName=LinuxHost
hotkeys\3\actions\2\type=2
hotkeys\3\actions\2\typeScreenNames\1\typeScreenName=LinuxHost
hotkeys\3\actions\2\typeScreenNames\size=1
hotkeys\3\actions\size=2
hotkeys\3\keys\1\key=4
hotkeys\3\keys\size=1
hotkeys\size=3

[dragon788]

Some additional learnings now that I set up a new "host" machine and forgot to backup my Synergy configuration.

From my notes on the forum post mentioned above:

Instead I did a selective remapping in the wizard of the improperly detected button 4 (which should be 6) to Meta+[ and then mapped button 3 (the middle click, only temporarily which I then corrected to button 7 in the exported config) and did a "Save configuration as" to ~/.synergy.conf. This file is supposedly loaded by default if it exists, but being explicit is better. I closed the Synergy GUI and then made my fixes to the exported file (changing mouse(4) to mouse(6) and mouse(3) to mouse(7)) and then I opened Synergy again and told it to load that config from the "Use existing configuration" (because the default config syntax in ~/.config/Synergy/Synergy.conf is inscrutable, and also because it auto saves when you open/close the Synergy GUI, which makes changing things on the fly rather difficult).

The one thing I didn't realize needed to happen in this sequence, is AFTER you add the mouse buttons to the hotkeys and a dummy "action" to each of them, you need to "Apply" this server configuration before the "Save configuration as" will pick up the changes and output them to the file you specify.

It appears the "Save" assumes a running/validated config, so if you made some broken changes to the point where "Apply" fails, you wouldn't end up with a totally broken state and could maybe go back and fix the issues.