precise wheel event for the html5 client

[totaam]

Follow up from #1611.

[totaam]

Done in r18920, the html5 client will now trigger precise scroll events if the server has uinput enabled:

UInput.wheel_motion(4, 0.5740) REL_WHEEL: 0.7+17.22=17.92

@maxmylyn: works for me, could be interesting for you guys. Do we need to map the macos scroll direction differently? (ie: is it somehow normalized the "right" way by some browsers)

[totaam]

2018-04-20 18:20:27: maxmylyn commented

---

Checked with Firefox and Chrome in OSX - and yes the scroll direction is reversed.

Checked with a 19034 Fedora 26 server.

[totaam]

Checked with Firefox and Chrome in OSX - and yes the scroll direction is reversed.

Not sure if that means that we're doing the right thing or that we need to invert the values on macos. Please clarify.

[totaam]

2018-04-24 20:26:36: maxmylyn commented

---

We need to invert the values on MacOS but only for the horizontal. That would bring it in line with local MacOS applications.

[totaam]

We need to invert the values on MacOS but only for the horizontal. That would bring it in line with local MacOS applications.

Did you test horizontal scrolling with a non-macos OS to compare? (ideally ms windows)
What application did you use to decide what is the desired scroll direction? (both native and through xpra)

I only have horizontal buttons, no wheel on any of my test devices. Those events come up a individual clicks, and they're using the same button number (4 and 5) as what vertical scrolling is meant to use (with r19072 to get javascript console debug logging with "mouse" debug enabled):

click: 4 true 453 228
click: 5 false 452 228

So r19073 remaps those buttons to 8 / 9, since that's what xev sees without xpra - I'm not 100% sure that's right though.
On windows using those button triggers navigation - making it impossible to figure out the button number that javascript should be seeing.
On the mac mini, the left and right horizontal buttons both trigger button 3 (middle click)...

[totaam]

2018-06-06 18:48:48: maxmylyn commented

---

I made a serious mistake when testing this ticket. I got this ticket and #1157 mixed up, so I was testing this with the Wacom Tablet. As such, the Wacom tablet X-direction was reversed not the mouse buttons. Those were working as expected and as such are now reversed in the X-direction.

I apologize profusely. Reversing the buttons again will make it work as expected.

[totaam]

r19574 swaps left and right. Please confirm that this fixes things so that I can backport.

[totaam]

2018-06-06 19:08:49: maxmylyn commented

---

I upped my server from r19572 to r19574 and I see no change. It's still reversed.

I wonder if there's something else going on here - I'll update my laptop which has an Apple trackpad versus my Logitech MX, and see if I can get ahold of an "Official" Apple Mouse.

[totaam]

I upped my server from r19572 to r19574 and I see no change. It's still reversed.

Change reverted in r19575.
This ticket is about scrolling, which is usually done using wheels or touchpad gestures.

Please provide xev button numbers and the server's "-d mouse".

[totaam]

2018-06-07 23:36:52: maxmylyn commented

---

Oh so it looks like I really have no idea what I'm doing then.

So I double checked this with my laptop's trackpad (after 4 hours of updates, I'm not even joking) and the horizontal scroll is definitely reversed as of 19581.

Here's a snippet of me scrolling to the left (as in my physical fingers are moving to the left), but the image I'm zoomed in on moves to the right (incorrectly, I verified with local Chrome that it should be moving to the left with my fingers).

2018-06-07 15:33:37,713 move_pointer(2, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:33:37,714 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:33:37,714 xtest_fake_button(7, 1)
2018-06-07 15:33:37,714 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 2, 7, 0, [447, 778], [], []])
2018-06-07 15:33:37,714 client X11ServerSource(1 : Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576)): server window position: (2, 202), client window position: (2, 202, 1276, 985)
2018-06-07 15:33:37,714 raising WindowModel(0x1000001)
2018-06-07 15:33:37,714 move_pointer(2, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:33:37,714 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:33:37,715 xtest_fake_button(7, 0)
2018-06-07 15:33:37,715 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 2, 7, 1, [447, 778], [], []])
2018-06-07 15:33:37,718 client X11ServerSource(1 : Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576)): server window position: (2, 202), client window position: (2, 202, 1276, 985)
2018-06-07 15:33:37,718 raising WindowModel(0x1000001)
2018-06-07 15:33:37,719 move_pointer(2, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:33:37,719 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:33:37,719 xtest_fake_button(7, 1)
2018-06-07 15:33:37,719 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 2, 7, 0, [447, 778], [], []])
2018-06-07 15:33:37,719 client X11ServerSource(1 : Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576)): server window position: (2, 202), client window position: (2, 202, 1276, 985)
2018-06-07 15:33:37,719 raising WindowModel(0x1000001)
2018-06-07 15:33:37,720 move_pointer(2, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:33:37,720 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:33:37,720 xtest_fake_button(7, 0)
2018-06-07 15:33:37,720 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 0, 7, 1, [447, 778], [], []])
2018-06-07 15:33:37,720 move_pointer(0, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:33:37,720 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:33:37,720 xtest_fake_button(7, 1)
2018-06-07 15:33:37,720 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 0, 7, 0, [447, 778], [], []])
2018-06-07 15:33:37,721 move_pointer(0, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:33:37,721 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:33:37,721 xtest_fake_button(7, 0)
2018-06-07 15:33:37,937 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 2, 7, 1, [447, 778], [], []])
2018-06-07 15:33:37,939 client X11ServerSource(1 : Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576)): server window position: (2, 202), client window position: (2, 202, 1276, 985)
2018-06-07 15:33:37,939 raising WindowModel(0x1000001)
2018-06-07 15:33:37,940 move_pointer(2, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:33:37,940 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:33:37,941 xtest_fake_button(7, 1)
2018-06-07 15:33:37,942 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 2, 7, 0, [447, 778], [], []])
2018-06-07 15:33:37,942 client X11ServerSource(1 : Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576)): server window position: (2, 202), client window position: (2, 202, 1276, 985)
2018-06-07 15:33:37,943 raising WindowModel(0x1000001)
2018-06-07 15:33:37,943 move_pointer(2, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:33:37,943 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:33:37,944 xtest_fake_button(7, 0)

For reference (not sure if it's useful or not), here's a snippet of the correct scroll direction in the verticle - moving my fingers down:

2018-06-07 15:35:27,133 move_pointer(2, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:35:27,133 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:35:27,134 xtest_fake_button(5, 1)
2018-06-07 15:35:27,134 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 2, 5, 0, [447, 778], [], []])
2018-06-07 15:35:27,134 client X11ServerSource(1 : Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576)): server window position: (2, 202), client window position: (2, 202, 1276, 985)
2018-06-07 15:35:27,135 raising WindowModel(0x1000001)
2018-06-07 15:35:27,135 move_pointer(2, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:35:27,135 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:35:27,135 xtest_fake_button(5, 0)
2018-06-07 15:35:27,182 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 2, 5, 1, [447, 778], [], []])
2018-06-07 15:35:27,183 client X11ServerSource(1 : Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576)): server window position: (2, 202), client window position: (2, 202, 1276, 985)
2018-06-07 15:35:27,183 raising WindowModel(0x1000001)
2018-06-07 15:35:27,183 move_pointer(2, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:35:27,184 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:35:27,184 xtest_fake_button(5, 1)
2018-06-07 15:35:27,184 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 2, 5, 0, [447, 778], [], []])
2018-06-07 15:35:27,185 client X11ServerSource(1 : Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576)): server window position: (2, 202), client window position: (2, 202, 1276, 985)
2018-06-07 15:35:27,185 raising WindowModel(0x1000001)
2018-06-07 15:35:27,185 move_pointer(2, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:35:27,185 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:35:27,185 xtest_fake_button(5, 0)
2018-06-07 15:35:27,232 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 0, 5, 1, [447, 778], [], []])
2018-06-07 15:35:27,232 move_pointer(0, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:35:27,232 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:35:27,232 xtest_fake_button(5, 1)
2018-06-07 15:35:27,232 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 0, 5, 0, [447, 778], [], []])
2018-06-07 15:35:27,232 move_pointer(0, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:35:27,233 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:35:27,233 xtest_fake_button(5, 0)
2018-06-07 15:35:27,314 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 0, 5, 1, [447, 778], [], []])
2018-06-07 15:35:27,315 move_pointer(0, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:35:27,315 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:35:27,315 xtest_fake_button(5, 1)
2018-06-07 15:35:27,315 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 0, 5, 0, [447, 778], [], []])
2018-06-07 15:35:27,316 move_pointer(0, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:35:27,316 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:35:27,316 xtest_fake_button(5, 0)
2018-06-07 15:35:27,668 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 0, 5, 1, [447, 778], [], []])
2018-06-07 15:35:27,669 move_pointer(0, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:35:27,669 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:35:27,670 xtest_fake_button(5, 1)
2018-06-07 15:35:27,671 process_button_action(Protocol(ws websocket: 192.168.1.81:14500 <- 192.168.1.145:49576), ['button-action', 0, 5, 0, [447, 778], [], []])
2018-06-07 15:35:27,673 move_pointer(0, [447, 778], -1) screen_no=-1, device=XTestPointerDevice
2018-06-07 15:35:27,674 xtest_fake_motion(-1, 447, 778)
2018-06-07 15:35:27,677 xtest_fake_button(5, 0)

Again, apologies. Passing back to you.

[totaam]

@afarr: do you have a win32 and / or macos client with a trackpad?
If so, can you trying horizontal scrolling? With the native client first, then html5 client.
I wanted to try with my laptop under Linux, but #2511 is in the way.
At least with my desktop, I verified with xev that the buttons pressed are the same through xpra as they are direct to X11. (4 + 5 for vertical scrolling, 8 and 9 for backwards and forwards - no horizontal on this mouse)

If you find that the wheel is reversed, please try:

xpra_cmd attach --mousewheel=invert-x

The default is --mousewheel=on.

[totaam]

2019-12-12 16:43:36: afarr commented

---

I have a win64 and macos both with a tracpad, so I can indeed try - but having a small issue with my vm host for server, so it may take a few days.

[totaam]

2019-12-12 21:44:07: afarr commented

---

Managed to try with OSX 10.12, using 3.0.3-24692 server with a 3.0-24039 osx python client.

Horizontal scrolling seems to work very well with the tracpad, almost too well? I suspect the Mac tracpad micro-event reporting, or whatever it is called, is reporting events in smaller 'increments' and higher quantities, so the horizontal scrolling is very fast (though not out of control, just fast).

Using the Mac Chrome 78 as html5 client, I am virtually unable to do any horizontal scrolling, but that seems to be because the Chrome is locally catching the horizontal scrolling motion and seems to want to show off a "feature" of using that horizontal scrolling as a forward or back key for the browser? So instead of scrolling right, the browser tries to interpret the scroll as the forward button for the browser.

In the case of a local page, if I make the browser very narrow, then I can horizontally scroll on an xpra page, for example, but other pages that I suspect are using extensions for some functionality (outlook sharepoint spreadsheets, for example, since they're always very wide and in need of horizontal scrolling), I am not able to horizontally scroll even on a local page, because the browser is intercepting that motion unless the loaded page is doing... something?

Likewise, with the Chrome as an html5 client, the xpra session chromium-browser page content is ... also failing to do the magic something?... so the local browser intercepts the horizontal scrolling events and shows off its "features", rather than passing the events along (which would presumably then work, since it works for the python client which doesn't have that "nifty Chrome feature" to get in the way).

I'm not sure what might log the browser intercept of the tracpad swipes... console logs?

I'll try on the win64 early next week if you think its worth the effort?

[totaam]

Managed to try with OSX 10.12, using 3.0.3-24692 server with a 3.0-24039 osx python client.

Assuming that this is the same version as in #2515, that's a Python2 / GTK2 build.
Can you try with a Python3 / GTK3 build to make sure there are no regressions there? (v3.0.3 or later)

Horizontal scrolling seems to work very well with the tracpad, almost too well?

Cool. No need to invert horizontal scrolling on macos then?
(as in: it goes in the direction a macos user will expect)

I suspect the Mac tracpad micro-event reporting, or whatever it is called, is reporting events in smaller 'increments' and higher quantities, so the horizontal scrolling is very fast (though not out of control, just fast).

We normalize the values we get from macos.
Depending on whether we get "precise" or "regular" scroll events, the result is slightly different.
The -d mouse output should show the wheel_event_handler and normalize_precision calls.
We can adjust this normalization:

• for non-precise events, the default is XPRA_OSX_WHEEL_MULTIPLIER=100. Using a lower value will make it scroll more slowly.
• for "precise" events (4th argument to wheel_event_handler is True), since the default value is XPRA_OSX_WHEEL_PRECISE_MULTIPLIER=1, you can't make it slower, so r24719 adds XPRA_OSX_WHEEL_DIVISOR=10 which you can also use to fine tune scroll wheel speed (applies to both "regular" and "precise" events).

Using the Mac Chrome 78 as html5 client, I am virtually unable to do any horizontal scrolling, but that seems to be because the Chrome is locally catching the horizontal scrolling motion and seems to want to show off a "feature" of using that horizontal scrolling as a forward or back key for the browser?

Right, add to that the fact that Javascript is likely to do its own normalization... fun!

I'll try on the win64 early next week if you think its worth the effort?

Yes please.
The key thing to close this ticket is to figure out if we need to invert horizontal scrolling direction or not. Earlier comments from max seem to indicate that we should? but comment:4 is on macos! (not sure about comment:11)

[totaam]

2019-12-17 00:33:25: afarr commented

---

Ok, managed to test a bit with 3.0.3-24692 Fedora 30 server and 3.0.3-r24690 windows client, from your dists list.

Oddly, the python client will not launch chromium-browser, when started from an xterm... but the html5 client will? (I'll look into that once I have a bright idea of what to check.)

Using Firefox (server-side) to open windows &/or spreadsheets to scroll horizontally, I find that the horizontal scrolling simply doesn't work.

With -d mouse enabled I literally see no logs whatsoever with the python client while the mouse icon changed into a horizontal-scrolling icon (Windows laptop feature, turns out to be handy for the first time ever).

With the html5 client (Chrome 79), still using Firefox server-side, the horizontal scrolling seem to be the reverse of what I would expect with Windows (in both cases if I move my fingers from left to right on the trac pad, that produces a scroll "leftward" across the window... or, maybe I should say it say left-to-right produces a "pull leftward"... but with Windows I think I would expect left-to-right to produce a "push rightward"... or scroll rightward scrolling across the page... if that makes any sense?).

Since the OSX produces an "intuitive" horizontal scroll, I didn't try launching the client with the scroll reverse flag.
The Windows python client doesn't respond to the tracpad horizontal scroll, so the reverse flag doesn't do anything (still fails to horizontally scroll).

The OSX html5 client seems like it might work, if the horizontal scroll command could get past the "browser feature".
The Windows html5 client works, but is the reverse of Windows "intuitive"... and I wasn't successful in my brief search for a means to pass the reversal flag for the html5 client connection.

Ohh, and I double checked with the 3.0.3-r24690 on OSX also... no sign of horizontal scrolling regressions.

I'll see about trying out some of those wheel multiplier/divisor options when I get a chance (maybe I'll try both at the same time just to see what happens?).

I guess back to you in the meantime.

[totaam]

Oddly, the python client will not launch chromium-browser, when started from an xterm... but the html5 client will?

Are you sure that another instance wasn't already running for this user account?
What is the error message chrome spits out?

Using Firefox (server-side) to open windows &/or spreadsheets to scroll horizontally, I find that the horizontal scrolling simply doesn't work.

Bummer. I may have to borrow a windows laptop to debug this.
Or maybe I'll get a USB touchpad, I could hook one up to my win7 test box. This should work the same way, right?
I can't find anything in the GTK documentation about horizontal scroll events. (they do have a window widget that handles it - but we want the raw events...)
Hell, I even landed back on the xpra tracker whilst scouring pages after pages of google search results: #1131. See also #1615.

The Windows html5 client works, but is the reverse of Windows "intuitive"... and I wasn't successful in my brief search for a means to pass the reversal flag for the html5 client connection.

There wasn't one. But now there is: r24736 (+r24737 is swapping the default direction).
It is only enabled by default for horizontal scrolling on MacOS. Is that right?
Doesn't MacOS also reverse vertical scrolling?

New Fedora beta builds posted. Alternatively, you can use the latest copy of the html5 client here: [https://xpra.org/html5/connect.html].

---

I forgot to mention that to make things even more complicated, we also have 2 different ways of handling scrolling...
With XTest - which is the default, we use "chunky" events and accumulate the more small discrete values we get from "smooth scrolling" until we have enough for one chunk.
With uinput (#1611), we pass the small discrete values directly to the server side.
To use uinput, you need permissions to access /dev/uinput.
But let's not worry about this for now. Chunky events are easier for testing.

[totaam]

2019-12-17 23:34:00: afarr commented

---

Tried to give it a go with a beta 4.0-24692... but it took me 4 tries to realize that just because 92 > 37 doesn't mean that 24692 >= 24737.

Ooops.

As long as I had the server running though, I tried more with the launching of chromium-browser from an xterm with python 3.0.3 client vs. Chrome as html5 client.

The error logs in the xterm for the launching of chromium-browser are the same whichever client launches (and I still can't manage to sync any copy events from a Fedora server-side xterm to a Windows client-side clipboard-clipboard... so I typed the whole thing out, only to find my cache had been cleaned and that was all lost...) - suffice it to say it seems to be errors about the sandbox and some kind of .cc gpu response failure (but, again... the messages don't affect rendering of the browser for html5 client?).

After server re-re-re-connections with the python client, I thought to add a -d window, and found some client side output that at least acknowledged that a chromium-browser window ought to exist.

2019-12-17 15:17:26,004 make_new_window(..) client_window_classes=(<class 'xpra.
client.gl.gtk3.nativegl_client_window.GLClientWindow'>, <class 'xpra.client.gtk3
.client_window.ClientWindow'>), group_leader_window=<__gi__.GdkWin32Window objec
t at 0x2c972ce8 (GdkWin32Window at 0x061c9320)>
2019-12-17 15:17:26,005 <class 'xpra.client.gl.gtk3.nativegl_client_window.GLCli
entWindow'>(gtk3.client, <__gi__.GdkWin32Window object at 0x2c972ce8 (GdkWin32Wi
ndow at 0x061c9320)>, 0, 4, 168, 150, 1313, 853, 1050, 682, {b'xid': b'0xc00001'
, b'client-machine': b'xpra-lib-fed30-2', b'pid': 25324, b'title': b'New Tab - C
hromium', b'role': b'browser', b'class-instance': (b'chromium-browser', b'Chromi
um-browser'), b'window-type': (b'NORMAL',), b'size-constraints': {b'position': (
1212, 173), b'minimum-size': (508, 87)}, b'icon-title': b'', b'decorations': 0,
b'set-initial-position': True}, False, {}, WindowBorder(False, 0xD41D8C, 0.6, 5)
, (32767, 32767), [4096, 2048, 16, 16, 7, 7, 1, b'\xff\xff\xff\xff\xff\xff\xff\x
ff\xff\..\xff\xff', b''], 0)
2019-12-17 15:17:26,013 setup_window(1050, 682)
2019-12-17 15:17:26,013 new_backing(1050, 682) backing_class=<class 'xpra.client.gl.gtk_base.gl_drawing_area.GLDrawingArea'>
2019-12-17 15:17:26,014 make_new_backing(<class 'xpra.client.gl.gtk_base.gl_drawing_area.GLDrawingArea'>, 1313, 853, 1313, 853) effective backing class=<class 'xpra.client.gl.gtk_base.gl_drawing_area.GLDrawingArea'>, server alpha=False, win
dow alpha=False
2019-12-17 15:17:26,015 set_window_type(['NORMAL']) hints=0
2019-12-17 15:17:26,016 make_new_window(..) window(4)=GLClientWindow(4 : gtk3.GLDrawingArea(4, (1050, 682), None))
2019-12-17 15:17:26,032 Win32Hooks: window frame size is 8x8
2019-12-17 15:17:26,033 Win32Hooks: message_map={36: <bound method Win32Hooks.on_getminmaxinfo of <xpra.platform.win32.window_hooks.Win32Hooks object at 0x2c985298>>}
2019-12-17 15:17:26,201 GL do_configure_event(<Gdk.EventConfigure object at 0x2c97fb90 (void at 0x061c8228)>)
2019-12-17 15:17:26,203 GLClientWindow(1 : gtk3.GLDrawingArea(1, (1141, 277), None)).do_map_event(<Gdk.EventAny object at 0x10d90438 (void at 0x061c82a0)>) OR=False
2019-12-17 15:17:26,204 GL do_configure_event(<Gdk.EventConfigure object at 0x10d90438 (void at 0x061c80c0)>)
2019-12-17 15:17:26,323 GL do_configure_event(<Gdk.EventConfigure object at 0x10d90438 (void at 0x061c8408)>)
2019-12-17 15:17:26,328 GLClientWindow(2 : gtk3.GLDrawingArea(2, (499, 316), None)).do_map_event(<Gdk.EventAny object at 0x10d90438 (void at 0x061c81b0)>) OR=False
2019-12-17 15:17:26,330 GL do_configure_event(<Gdk.EventConfigure object at 0x10d90438 (void at 0x061c85e8)>)
2019-12-17 15:17:26,390 GL do_configure_event(<Gdk.EventConfigure object at 0x10d90438 (void at 0x061c87c8)>)
2019-12-17 15:17:26,397 GLClientWindow(4 : gtk3.GLDrawingArea(4, (1050, 682), None)).do_map_event(<Gdk.EventAny object at 0x10d90438 (void at 0x061c8a20)>) OR=False
2019-12-17 15:17:26,398 GL do_configure_event(<Gdk.EventConfigure object at 0x10d90438 (void at 0x061c8a98)>)
2019-12-17 15:17:26,497 cairo_paint_border(<cairo.Context object at 0x2c6f3c30>, None)
2019-12-17 15:17:26,500 cairo_paint_border(<cairo.Context object at 0x2c6f3c60>, None)
2019-12-17 15:17:26,511 cairo_paint_border(<cairo.Context object at 0x2c6f3bb0>, None)
2019-12-17 15:17:26,517 cairo_paint_border(<cairo.Context object at 0x2c6f3c60>, None)
2019-12-17 15:17:26,530 cairo_paint_border(<cairo.Context object at 0x2c6f3ba0>, None)
2019-12-17 15:17:27,837 sound output using 'opus' audio codec
2019-12-17 15:17:32,298 cairo_paint_border(<cairo.Context object at 0x2fffc470>, None)
2019-12-17 15:17:32,314 cairo_paint_border(<cairo.Context object at 0x2fffc510>, None)
2019-12-17 15:17:32,331 cairo_paint_border(<cairo.Context object at 0x2fffc690>, None)
2019-12-17 15:17:32,343 cairo_paint_border(<cairo.Context object at 0x2fffc690>, None)
2019-12-17 15:17:32,350 cairo_paint_border(<cairo.Context object at 0x2fffc690>, None)
2019-12-17 15:17:32,369 cairo_paint_border(<cairo.Context object at 0x2fffc100>, None)
2019-12-17 15:17:32,382 cairo_paint_border(<cairo.Context object at 0x2fffc540>, None)
2019-12-17 15:17:32,400 cairo_paint_border(<cairo.Context object at 0x2fffc690>, None)
2019-12-17 15:17:32,416 cairo_paint_border(<cairo.Context object at 0x2fffc690>, None)
2019-12-17 15:17:32,431 cairo_paint_border(<cairo.Context object at 0x2fffc590>, None)
2019-12-17 15:17:32,452 cairo_paint_border(<cairo.Context object at 0x2fffc590>, None)
2019-12-17 15:17:32,464 cairo_paint_border(<cairo.Context object at 0x2fffc590>, None)
2019-12-17 15:17:32,490 cairo_paint_border(<cairo.Context object at 0x2fffc590>, None)

I suppose I can make a new ticket out of this if there's anything there of interest?

In the meantime, I'll have to wait and try again when the repo successfully pulls down the newer beta.

[totaam]

2019-12-17 23:40:46: afarr uploaded file ticket-1797_chromium-oddness.txt (353.8 KiB)

xpra-info for python launch of chromium browser (with client disconnected)

[totaam]

Tried to give it a go with a beta 4.0-24692... but it took me 4 tries to realize that just because 92 > 37 doesn't mean that 24692 >= 24737.

Damn, they've removed the createrepo command from Gentoo, so the repository creation failed and although the Fedora repos had r24737 RPMs in them, the repodata file did not know about them and so it didn't give you the option to upgrade. Should work now.

The error logs in the xterm for the launching of chromium-browser are the same whichever client launches (and I still can't manage to sync any copy events from a Fedora server-side xterm to a Windows client-side clipboard-clipboard... so I typed the whole thing out, only to find my cache had been cleaned and that was all lost...)

Right, the xterm selection syncs to PRIMARY, and there seems to be a problem when choosing PRIMARY with the win32 client - will fix.
FYI: you can also send the command output to a file, then send that file to the client using FileTransfers.
And now made even easier by #2518.

suffice it to say it seems to be errors about the sandbox and some kind of .cc gpu response failure (but, again... the messages don't affect rendering of the browser for html5 client?).

Yeah, those are probably harmless.

After server re-re-re-connections with the python client, I thought to add a -d window, and found some client side output that at least acknowledged that a chromium-browser window ought to exist.

I am pretty confident that this bug is already fixed: #2514. Grab a newer client and things should work.

[totaam]

2020-01-02 20:18:20: afarr commented

---

Tried some more with the new 4.0 Fedora server - xpra v4.0-24771.

Continuing to use Chrome 78 on OSX 10.12 as html5 client, I was able to manage some horizontal scrolling on a google spreadsheet in a server-side chromium-browser app (which scrolled in the "usual" mac-reverse way, moving fingers from right-to-left across the tracpad "pulling" the page leftward, so the horizontal position of the spreadsheet shifts "rightward" across the sheet as it moves leftward and the "focus" remains stationary... so that the right-to-left motion moves the scrollbar right-ward... though I couldn't then "pull" left-to-right without the Chrome intercepting the drag and interpreting it as a 'back button' on the browser itself event... which then 'backed' the page to the blank start page rather than the https://10.0.3.148:1239 xpra server page, if that all makes sense).

Unfortunately, when I go to xpra.org/beta/MacOS the latest Xpra-Python3 client I can find is 4.0-24670.dmg (maybe OSX beta repo shares the same problem as those Fedora builds?)

With a Chrome 79 on Windows 7 as html5 client, the horizontal scrolling on the google spreadsheet works well in both directions (and it is working in the "correct" windows direction, with a right-to-left tracpad motion "pulling" the "focus" from right to left across the spreadsheet... so that the right-to-left motion moves the scrollbar left-ward).

Unfortunately... stay with me here... when I shifted the session back to the OSX html5 client, it began handling the horizontal scrolling in the windows-like direction (right-to-left moves scrollbar left, no longer right-ward).

Opening a new tab on the OSX Chrome html5 client for a "fresh connection" (rather than using the Connect button from the connect.html page)... the OSX html5 client once again behaves OSX-like. Shift the session back and forth with the Connect buttons, however, and the horizontal scrolling "gets lazy" and behaves Windows-like again?

Trying again with -d mouse it looks like the scrolling logs are rather different from what I see with windows... I can't tell anything is happening from the logs.

With a "fresh connection" on OSX (right-to-left moves scroll bar right-ward) I see this in the logs.

2020-01-02 11:57:43,648 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), [b'button-action', 0, 7, 1, [441, 758], [], []])
2020-01-02 11:57:43,649 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), 0, [441, 758], -1)
2020-01-02 11:57:43,649 move_pointer(0, [441, 758], -1) screen_no=-1, device=XTestPointerDevice, position=(441, 758)
2020-01-02 11:57:43,649 xtest_fake_motion(-1, 441, 758)
2020-01-02 11:57:43,649 xtest_fake_button(7, 1)
2020-01-02 11:57:43,650 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), [b'button-action', 0, 7, 0, [441, 758], [], []])
2020-01-02 11:57:43,650 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), 0, [441, 758], -1)
2020-01-02 11:57:43,651 move_pointer(0, [441, 758], -1) screen_no=-1, device=XTestPointerDevice, position=(441, 758)
2020-01-02 11:57:43,651 xtest_fake_motion(-1, 441, 758)
2020-01-02 11:57:43,651 xtest_fake_button(7, 0)
2020-01-02 11:57:43,909 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), [b'button-action', 3, 7, 1, [441, 758], [], []])
2020-01-02 11:57:43,910 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), 3, [441, 758], -1)
2020-01-02 11:57:43,910 move_pointer(3, [441, 758], -1) screen_no=-1, device=XTestPointerDevice, position=(441, 758)
2020-01-02 11:57:43,910 xtest_fake_motion(-1, 441, 758)
2020-01-02 11:57:43,910 xtest_fake_button(7, 1)
2020-01-02 11:57:43,911 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), [b'button-action', 3, 7, 0, [441, 758], [], []])
2020-01-02 11:57:43,911 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), 3, [441, 758], -1)
2020-01-02 11:57:43,912 move_pointer(3, [441, 758], -1) screen_no=-1, device=XTestPointerDevice, position=(441, 758)
2020-01-02 11:57:43,912 xtest_fake_motion(-1, 441, 758)
2020-01-02 11:57:43,912 xtest_fake_button(7, 0)
2020-01-02 11:57:44,099 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), [b'button-action', 0, 4, 1, [441, 758], [], []])
2020-01-02 11:57:44,099 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), 0, [441, 758], -1)
2020-01-02 11:57:44,100 move_pointer(0, [441, 758], -1) screen_no=-1, device=XTestPointerDevice, position=(441, 758)
2020-01-02 11:57:44,100 xtest_fake_motion(-1, 441, 758)
2020-01-02 11:57:44,100 xtest_fake_button(4, 1)
2020-01-02 11:57:44,101 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), [b'button-action', 0, 4, 0, [441, 758], [], []])
2020-01-02 11:57:44,101 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), 0, [441, 758], -1)
2020-01-02 11:57:44,101 move_pointer(0, [441, 758], -1) screen_no=-1, device=XTestPointerDevice, position=(441, 758)
2020-01-02 11:57:44,101 xtest_fake_motion(-1, 441, 758)
2020-01-02 11:57:44,102 xtest_fake_button(4, 0)
2020-01-02 11:57:44,176 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), [b'button-action', 0, 7, 1, [441, 758], [], []])
2020-01-02 11:57:44,176 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), 0, [441, 758], -1)
2020-01-02 11:57:44,176 move_pointer(0, [441, 758], -1) screen_no=-1, device=XTestPointerDevice, position=(441, 758)
2020-01-02 11:57:44,177 xtest_fake_motion(-1, 441, 758)
2020-01-02 11:57:44,177 xtest_fake_button(7, 1)
2020-01-02 11:57:44,177 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), [b'button-action', 0, 7, 0, [441, 758], [], []])
2020-01-02 11:57:44,177 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), 0, [441, 758], -1)
2020-01-02 11:57:44,178 move_pointer(0, [441, 758], -1) screen_no=-1, device=XTestPointerDevice, position=(441, 758)
2020-01-02 11:57:44,178 xtest_fake_motion(-1, 441, 758)
2020-01-02 11:57:44,178 xtest_fake_button(7, 0)
2020-01-02 11:57:44,541 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), [b'button-action', 3, 7, 1, [441, 758], [], []])
2020-01-02 11:57:44,542 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), 3, [441, 758], -1)
2020-01-02 11:57:44,542 move_pointer(3, [441, 758], -1) screen_no=-1, device=XTestPointerDevice, position=(441, 758)
2020-01-02 11:57:44,542 xtest_fake_motion(-1, 441, 758)
2020-01-02 11:57:44,542 xtest_fake_button(7, 1)
2020-01-02 11:57:44,543 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), [b'button-action', 3, 7, 0, [441, 758], [], []])
2020-01-02 11:57:44,543 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57090), 3, [441, 758], -1)
2020-01-02 11:57:44,543 move_pointer(3, [441, 758], -1) screen_no=-1, device=XTestPointerDevice, position=(441, 758)
2020-01-02 11:57:44,544 xtest_fake_motion(-1, 441, 758)
2020-01-02 11:57:44,544 xtest_fake_button(7, 0)

Are the 3's vs. 0's the only expected change?

Meanwhile, after then connecting with a Connect button on a connect.html tab, when the right-to-left tracpad moves the scrollbar left-ward:

2020-01-02 12:02:22,956 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57276), [b'button-action', 0, 6, 1, [438, 705], [], []])
2020-01-02 12:02:22,956 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57276), 0, [438, 705], -1)
2020-01-02 12:02:22,957 move_pointer(0, [438, 705], -1) screen_no=-1, device=XTestPointerDevice, position=(438, 705)
2020-01-02 12:02:22,957 xtest_fake_motion(-1, 438, 705)
2020-01-02 12:02:22,958 xtest_fake_button(6, 1)
2020-01-02 12:02:22,959 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57276), [b'button-action', 0, 6, 0, [438, 705], [], []])
2020-01-02 12:02:22,959 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57276), 0, [438, 705], -1)
2020-01-02 12:02:22,960 move_pointer(0, [438, 705], -1) screen_no=-1, device=XTestPointerDevice, position=(438, 705)
2020-01-02 12:02:22,960 xtest_fake_motion(-1, 438, 705)
2020-01-02 12:02:22,960 xtest_fake_button(6, 0)
2020-01-02 12:02:24,590 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57276), [b'button-action', 0, 6, 1, [438, 705], [], []])
2020-01-02 12:02:24,591 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57276), 0, [438, 705], -1)
2020-01-02 12:02:24,591 move_pointer(0, [438, 705], -1) screen_no=-1, device=XTestPointerDevice, position=(438, 705)
2020-01-02 12:02:24,592 xtest_fake_motion(-1, 438, 705)
2020-01-02 12:02:24,592 xtest_fake_button(6, 1)
2020-01-02 12:02:24,593 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57276), [b'button-action', 0, 6, 0, [438, 705], [], []])
2020-01-02 12:02:24,593 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.35:57276), 0, [438, 705], -1)
2020-01-02 12:02:24,593 move_pointer(0, [438, 705], -1) screen_no=-1, device=XTestPointerDevice, position=(438, 705)
2020-01-02 12:02:24,593 xtest_fake_motion(-1, 438, 705)
2020-01-02 12:02:24,594 xtest_fake_button(6, 0)

... I don't see anything in those logs.

And, for comparison, with a windows right-to-left tracpad motion (which behaves the same whether with a "fresh connection" or a shifted one using the Connect button):

2020-01-02 12:05:39,116 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.36:62292), [b'button-action', 3, 6, 1, [297, 525], [b'mod2'], []])
2020-01-02 12:05:39,118 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.36:62292), 3, [297, 525], -1)
2020-01-02 12:05:39,120 move_pointer(3, [297, 525], -1) screen_no=-1, device=XTestPointerDevice, position=(297, 525)
2020-01-02 12:05:39,120 xtest_fake_motion(-1, 297, 525)
2020-01-02 12:05:39,121 xtest_fake_button(6, 1)
2020-01-02 12:05:39,127 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.36:62292), [b'button-action', 3, 6, 0, [297, 525], [b'mod2'], []])
2020-01-02 12:05:39,128 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.36:62292), 3, [297, 525], -1)
2020-01-02 12:05:39,128 move_pointer(3, [297, 525], -1) screen_no=-1, device=XTestPointerDevice, position=(297, 525)
2020-01-02 12:05:39,129 xtest_fake_motion(-1, 297, 525)
2020-01-02 12:05:39,129 xtest_fake_button(6, 0)
2020-01-02 12:05:39,130 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.36:62292), [b'button-action', 0, 6, 1, [297, 525], [b'mod2'], []])
2020-01-02 12:05:39,130 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.36:62292), 0, [297, 525], -1)
2020-01-02 12:05:39,131 move_pointer(0, [297, 525], -1) screen_no=-1, device=XTestPointerDevice, position=(297, 525)
2020-01-02 12:05:39,131 xtest_fake_motion(-1, 297, 525)
2020-01-02 12:05:39,132 xtest_fake_button(6, 1)
2020-01-02 12:05:39,132 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.36:62292), [b'button-action', 0, 6, 0, [297, 525], [b'mod2'], []])
2020-01-02 12:05:39,133 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.36:62292), 0, [297, 525], -1)
2020-01-02 12:05:39,133 move_pointer(0, [297, 525], -1) screen_no=-1, device=XTestPointerDevice, position=(297, 525)
2020-01-02 12:05:39,133 xtest_fake_motion(-1, 297, 525)
2020-01-02 12:05:39,134 xtest_fake_button(6, 0)
2020-01-02 12:05:39,172 process_button_action(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.36:62292), [b'button-action', 3, 6, 1, [297, 525], [b'mod2'], []])
2020-01-02 12:05:39,172 do_process_mouse_common(WebSocket(wss socket: 10.0.3.148:1239 <- 10.0.4.36:62292), 3, [297, 525], -1)
2020-01-02 12:05:39,173 move_pointer(3, [297, 525], -1) screen_no=-1, device=XTestPointerDevice, position=(297, 525)
2020-01-02 12:05:39,173 xtest_fake_motion(-1, 297, 525)
2020-01-02 12:05:39,173 xtest_fake_button(6, 1)

... which again seems to just have the 3's vs. the 0's indicating the horizontal scrolling, but in this case the scrollbar is moving left-ward.

With Windows python client 4.0-24829 I am still getting no horizontal scrolling response, though the tracpad's vertical scrolling is working (so some input is getting caught, better than nothing?)... and I am able to launch chromium-browser from the xterm again.

I do see an odd error about a network interface in the client logs though.

2020-01-02 12:10:02,496 Error: failed to query network interface:
2020-01-02 12:10:02,497  module 'comtypes.gen.WbemScripting' has no attribute 'ISWbemLocator'

... maybe something to do with using Windows 7 that should really be updated soon?

I'll roll back to 3.0.3 and go through the clients again in another comment.

[totaam]

2020-01-02 22:07:55: afarr commented

---

And, repeating with Fedora 30 3.0.4-24778...

With Chrome 78 on OSX 10.12 as html5 client, the horizontal scrolling on a google doc spreadsheet run in chromium-browser server side is always windows-like in its horizontal scrolling, whether using a "fresh connection" or a Connect button (right-to-left tracpad moves the scrollbar left-ward)... and with the 3.0.4-24778 server I couldn't find any debug options to reverse the horizontal scrolling on the connect.html page.

With Chrome 79 on Windows 7 as html5 client... for some reason the horizontal scrolling on a google doc spreadsheet run in a chromium-browser server side is OSX-like with its horizontal scrolling? (right-to-left tracpad motion moves scrollbar right ward, and also doesn't have an option to reverse horizontal scrolling for html5 client.

The Xpra-Python3-x86_64-3.0.4-24778.dmg client from the dists directory tracpad horizontal scrolling works exactly as expected/hoped for OSX with the same google doc spreadsheet on a chromium-browser running server side (right-to-left tracpad motion moves scrollbar to the right, as OSX expects).

The Xpra-Client-Python3-x86_64_Setup_3.0.4-24778.exe from your dists directory also doesn't register any tracpad horizontal scrolling events on Windows 7 (on a Lenovo ThinkPad, in case that at least narrows down those searches a little).

Ohh, and with the 3.0.4-24778 windows python client, I am again unable to render a chromium-browser window launched server side from an xterm (but, as mentioned, I have no problems doing so with the 4.0-24829 client). Oddly, the tab that should be displayed shows up in the process tray bottom left, but I can't make the application itself display.

I'll pass this back to you I guess. (Let me know if you want a separate ticket, maybe, for the 3.0.4 vs. 4.0 difference in launching chromium-browser? I have a suspicion that the Chrome already running locally is somehow causing some confusion with the Xpra forwarding of the chromium-browser?)

[totaam]

also doesn't have an option to reverse horizontal scrolling for html5 client

Until we know what solution works, r24736 + r24737 were only applied to trunk. Can you try that instead?

The latest beta builds should have this change, or you can use the online copy here: [https://xpra.org/html5/].

The Xpra-Client-Python3-x86_64_Setup_3.0.4-24778.exe from your dists directory also doesn't register any tracpad horizontal scrolling events on Windows 7

I suspect that this requires special touch device event registration with GTK, I will need a trackpad device to test.

Ohh, and with the 3.0.4-24778 windows python client, I am again unable to render a chromium-browser window launched server side from an xterm (but, as mentioned, I have no problems doing so with the 4.0-24829 client)

Damn. The 3.0.4 update was meant to fix that bug: #2466, which caused #2481, which caused #2491 which ended up fixing #2373...
Does this happen with opengl disabled? If so, please post the client's -d window output into a new ticket.
If not, please post your opengl information (ie: xpra_cmd opengl) and reopen #2466.

[totaam]

2020-01-03 21:30:33: afarr commented

---

Sorry, I think breaking up the replies for trunk vs. 3.0.4 resulted in the trunk comments being lost.

With the 4.0 Fedora server - xpra v4.0-24771... the horizontal scrolling works for both Chrome 78 html5 client on OSX 10.12 (assuming a mechanism to launch that doesn't allow for an active forward &/or back button, so that the tracpad feature of horizontal scrolling being caught by the browser as a forward or back button event won't be triggered) and Chrome 79 html5 client on Windows 7... and in each case works in the 'expected' direction - but only upon initial "direct connection", as described in comment:21 (which also has some logs).

Meanwhile... with the Chrome 78 html5 client on OSX, if the connection is made via the Connect button on the connect.html page, then the horizontal scrolling uses a "Windows-like" direction. (Windows html5 client works as expected whether direct connecting or using the connect.html link.)

So it looks like the change made in trunk should be back-ported to the 3.0.4 (once the connect.html issue is sorted out).

Also, as you expected, with the Xpra-Client-Python3-x86_64_Setup_3.0.4-24778.exe client, if I connect with Xpra_cmd.exe attach tcp:10.0.3.148:1234 --opengl=off I am able to launch the chromium-browser from an xterm... without the --opengl=off, I get the tray icon but no display of the application. (Previous tests were with a system with both Intel and Nvidia drivers, seeing the Intel greylist warning... today's test is with an Nvidia, with no greylist warning obviously... just for clarity.)

I should also note that, connecting over a vpn, if I had too many other applications also connecting over the vpn, the opengl ping test seemed to be resulting in a timeout and connection failure - just as an additional argument for some kind of user visible display to indicate that such a test is going on.

I'll pass this back to you again.

[totaam]

Meanwhile... with the Chrome 78 html5 client on OSX, if the connection is made via the Connect button on the connect.html page, then the horizontal scrolling uses a "Windows-like" direction.

Ah, r24903 fixes that.
When going via the connect page, we reverse vertical scrolling now instead of horizontal on macos - is that right? This should now be the not "windows-like" direction, which is what macos does? And we get this just by leaving the value alone instead of inverting it. (I assume the browser is giving us the "inverted" / "macos-like" value already)
This changes vertical too: that's what connecting directly was doing - so I assumed that was / still is correct?

I don't really understand how it happened, but the values for horizontal scrolling now look like they should be the same in v3.0.x... (leaving them alone) but you're saying the backport is needed there!?

Also, as you expected, with the Xpra-Client-Python3-x86_64_Setup_3.0.4-24778.exe client, if I connect with --opengl=off I am able to launch the chromium-browser from an xterm

Can you please add your opengl info into #2466.

I should also note that, connecting over a vpn, if I had too many other applications also connecting over the vpn, the opengl ping test seemed to be resulting in a timeout and connection failure

It shouldn't make any difference, the opengl probe happens before we try to connect. Odd. The new ticket below should make it clearer.

• just as an additional argument for some kind of user visible display to indicate that such a test is going on.

New ticket: #2540.

[totaam]

2020-01-06 20:09:01: afarr commented

---

Reopened #2466.

Updating the 3.0.4 server still gets me xpra v3.0.4-24778.
Enabling the beta repo only updates me to xpra v4.0-24771.

I wanted to re-test the new version because I'm starting to get confused myself - I don't remember seeing any issues with the vertical, only the horizontal scrolling with trac pads in html5 clients, and that only on the 3.0.4.
Once there are new builds I'll go through again, just to be able to comment again and have something to refer back to in order to un-confuse myself.

[totaam]

2020-01-09 23:37:18: afarr commented

---

I guess I'll pass this back to you for the moment.

Update to xpra v3.0.5-24928 server and launched with the usual command.

Trying to connect via https/wss I was getting only what looked like the usual cert errors (using a self-signed cert with no SubjectAlternateName, which Chrome will always treat as insecure and throw errors)... but the connection hangs and eventually times out.

Chrome 79 on Windows 7 and OSX both.

Tried again with http://10.0.3.148:1237, with the Main and Network debug options from the connect.html enabled.
The server logs are still just showing a connection timeout.

2020-01-09 15:28:19,465 Error: connection timed out: ws socket: 10.0.3.148:1237 <- 10.0.4.36:55919
2020-01-09 15:28:41,893 Error: connection timed out: ws socket: 10.0.3.148:1237 <- 10.0.4.36:55946

The client dev tool console logs indicate something about a keyname not defined?

connection_progress( Connecting to server ,  10.0.3.148:1237/index.html ,  40 )
Utilities.js:1 we have webworker support
Utilities.js:1 we can use websocket in webworker
Utilities.js:1 connection_progress( Opening WebSocket connection ,  ws://10.0.3.148:1237/index.html ,  60 )
Utilities.js:1 connection_progress( WebSocket connection established ,   ,  80 )
Utilities.js:1 sending hello
Utilities.js:1 legacy clipboard
Utilities.js:1 return all encodings:  Array(7)
Utilities.js:1 return all encodings:  Array(7)
Client.js:1 Uncaught ReferenceError: keyname is not defined
    at XpraClient._get_keycodes (Client.js:1)
    at XpraClient._make_hello (Client.js:1)
    at XpraClient._send_hello (Client.js:1)
    at XpraClient._process_open (Client.js:1)
    at XpraProtocolWorkerHost.XpraClient._route_packet [as packet_handler] (Client.js:1)
    at Worker.<anonymous> (Protocol.js:1)
Utilities.js:1 visibilitychange hidden= true connected= false
Protocol.js:1 WebSocket connection to 'ws://10.0.3.148:1237/index.html' failed: One or more reserved bits are on: reserved1 # 1, reserved21, reserved3 = 0
XpraProtocol.open @ Protocol.js:1
Utilities.js:1 websocket error:  undefined reason:  null
cerror @ Utilities.js:1
Utilities.js:1 audio-state: stopped
Utilities.js:1 connection closed: null

These fixes sure are being uncooperative...

[totaam]

Client.js:1 Uncaught ReferenceError: keyname is not defined

Sorry about that, this bug was fixed yesterday in 24934.
Updated xpra-html5 3.0.5 packages have been uploaded.

[totaam]

2020-01-21 20:27:32: afarr commented

---

Huh.
Tested again with 3.0.5-24939 Fedora 30 server using Chrome 79 as html5 client on Windows 7 and OSX 10.12 - and in both cases the horizontal scrolling (with a google spreadsheet displaying with a horizontal scroll bar) is "reversed" from what is "expected".

With Windows tracpad motion from left to right moves the scroll bar from right to left (reverse expected with Windows).

With OSX tracpad motion from left to right moves the scroll bar from left to right (also reverse of expected with OSX).

Motion is the same with an initial connection as with connection using the Connect button of the /connect.html page (in both cases).

In both cases, vertical scrolling moves in the "expected" direction.

Repeated also with 4.0-r25012 Fedora server and all behaviors are the same.

Passing it back to you so you can flip the behaviors for the horizontal scrolling.

[totaam]

Thanks!

Passing it back to you so you can flip the behaviors for the horizontal scrolling.

Done in r25032.
I think we can close this.