Gnome-shell-extension-gsconnect: Remote Control: Scroll Down doesn't work

[0x656b694d]

Describe the bug

The Scroll Down events are not handled with the remote control touch pad.

Steps To Reproduce:

1. Scroll Down in the remote control
2. See it doesn't scroll

Expected behavior

Should scroll

Support Log

The log generated while scrolling up, then scrolling down, then scrolling up again.

gsconnect.log.txt

System Details (please complete the following information):

• GSConnect version: 28
  
  
  
  • Installed from: GNOME Extensions Website
  
  
• GNOME/Shell version: 3.34
• Distro/Release: Ubuntu 19.10

GSConnect environment (if applicable):

• Paired Device(s): OnePlus 3T
• KDE Connect app version: 1.13.2
• Plugin(s): mouse

Additional Notes:

Scroll Up works.

[andyholmes]

Hmm, I can't reproduce this in Fedora 31. It might be a bug in Ubuntu 19.10. Does this work in Wayland or is it only broken in X11?

[0x656b694d]

Remote mouse doesn't work at all in Wayland. Please find the log attached. It says it is falling back to Atspi in the end, whatever it means:

ноя 02 20:35:48 org.gnome.Shell.Extensions.GSConnect[12539]: [/service/components/input.js:_ensureAdapter:419]: "Falling back to Atspi"
ноя 02 20:35:49 org.gnome.Shell.Extensions.GSConnect[2692]: dbus[12539]: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file ../../../dbus/dbus-message.c line 1366.
ноя 02 20:35:49 org.gnome.Shell.Extensions.GSConnect[2692]: This is normally a bug in some application using the D-Bus library.

gsconnect.log.txt

[andyholmes]

Hmm, that's a little hairy :S

Atspi is the older, accessibility interface we fall back to if Mutter's RemoteDesktop is not available. Atspi pretty much just doesn't work at all on Wayland, but it shouldn't be throwing errors like that either.

In Wayland with the RemoteDesktop sessions we can actually do proper touch scroll/drag events, but in X11 that didn't work for me so we simulate the mouse wheel (which is technically a button). However, in X11 I couldn't get the scroll-down button to work, so we're doing a "negative scroll-up" :stuck_out_tongue_closed_eyes:

I have to head out for awhile, but I'll have a look into what Ubuntu is doing this cycle with RemoteDesktop sessions this evening and get back to you. A lot of this older sort-of-works-sometimes junk is what I've started ripping out since v28 was released, so I might get you to test some new shiny stuff if you're up for it :)

[0x656b694d]

test some new shiny stuff

with pleasure!

[ferdnyc]

we simulate the mouse wheel (which is technically a button).

More-technically, two buttons! (One for each direction you can spin it.) :wink:

[andyholmes]

More-technically, two buttons! (One for each direction you can spin it.) :wink:

I actually couldn't find the evdev code for the down-wheel. That's why we're currently scrolling upwards backwards :D

[andyholmes]

Okay, I'm not sure I fixed much, but here's a latest Zip that at least removes the Atspi stuff:

[email protected]

Might be worth a shot, but I'll have another look tomorrow since I still can't reproduce the bug.

[0x656b694d]

Thanks for the update! The remote control doesn't work at all with this version, neither in Xorg nor in Wayland.
gsconnect.wayland.log

[0x656b694d]

gsconnect.xorg.log

[ferdnyc]

(To save some downloading and searching, they both just keep logging this, with no obvious prelude at all...)

ноя 05 23:32:18 gjs[23645]: JS ERROR: Error: RemoteDesktop not available
                               _ensureAdapter@/home/mikhail/.local/share/gnome-shell/extensions/[email protected]/service/components/input.js:374:23
                               async*movePointer@/home/mikhail/.local/share/gnome-shell/extensions/[email protected]/service/components/input.js:420:13
                               _handleInput@/home/mikhail/.local/share/gnome-shell/extensions/[email protected]/service/plugins/mousepad.js:176:17
                               handlePacket@/home/mikhail/.local/share/gnome-shell/extensions/[email protected]/service/plugins/mousepad.js:150:21
                               receivePacket@/home/mikhail/.local/share/gnome-shell/extensions/[email protected]/service/device.js:378:21
                               receive/<@/home/mikhail/.local/share/gnome-shell/extensions/[email protected]/service/protocol/core.js:276:25
                               @/home/mikhail/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js:1141:2

A thought, @0x656b694d : Do you have Screen Sharing turned on in the Sharing pane of gnome-control-center. I'm guessing that would be required, for GSConnect to deliver Remote Desktop-based input, yes @andyholmes ?

[andyholmes]

Ah dang, I just checked Ubuntu's build for mutter and it looks like they've decided to build without RemoteDesktop yet again.

Looks like it's going to be half-working, X11 only remote input for Ubuntu users for at least another 6 months :confounded:. I guess I'll have to revert pulling Atspi from the codebase and block it entirely on Wayland.

EDIT: oh wait, that seems to be only on non-Linux builds. I don't know what's going on here :confused:.

EDIT2: Nope, I was right after all.

[andyholmes]

Good news though, I found the scrolling bug:

https://github.com/andyholmes/gnome-shell-extension-gsconnect/blob/3050a7878a1cf35a6cf9b648b9253b74c7cc1967/src/service/components/atspi.js#L129-L135

So simple an idiot could have figured it out; too bad you're stuck with me mwaha.

[andyholmes]

Here's an updated Zip with Atspi added back and scrolling fixed. It will still crash GSConnect if you use it on Wayland, but I'll fix that in a bit:

[email protected]

[ferdnyc]

Good news though, I found the scrolling bug

This is why I miss actually compiling things, GCC would totally catch that.

[ferdnyc]

(Of course, good static analysis could catch it as well. Have you ever looked at Codacy? I've been running their scans on another project, just sort of on my own (they're not currently integrated into the repo CI, though they can be), and they've actually really helped improve the code. Fully GitHub-integratable and free for open source projects, in the vein of Travis et al.)

[andyholmes]

I tried codacy some months back, but the turn around time was pretty excessive. I think you get back benched if you don't pay, so I just went for eslint in TravisCI.

I have a feeling it wouldn't catch this one though, since I don't get that error on Fedora and there's nothing special about the way we use Atspi. I'm guessing it's related to Atspi just not working on Wayland so no one's bothered to test it in awhile. It will be interesting to see how they end up addressing a11y in Wayland and/or sandboxes, since I don't see an obvious way to expose it to applications without letting them abuse it.

[ferdnyc]

Oh, no, I just meant the

if ( condition ) {
  foo();
} else if ( same condition ) {
  bar();
}

...It'd _totally_ catch that. As we used to say in Boston, it's wicked smaat. :wink:

[ferdnyc]

It is _crazy_ slow, though, that's for sure. And laden with false positives / undifferentiated hits of wildly varying severity.

The codebase I'm running it on has 6 years of history with a lot of cowboy coding in it (including plenty of my own), so the first run flagged something like 1100 issues. I've addressed about 200 of them so far, including maybe 10-20 that were genuine bugs or potential bugs, but most of the rest are things that either aren't worth the PR to fix, can't be fixed, or shouldn't be fixed, and would all have to be excluded with control comments.

That's why I just run the reports myself and look them over, submit any fixes needed manually. Giving it control over our PRs would be a disaster.

But, that being said, there are those few real issues it catches. I started using it when someone spotted one of these bugs in our C++ code:

if ( condition )
    var == integer_value;

Turned out it'd been there for YEARS, unnoticed. Codacy flagged it instantly. (g++ -Wall would've, too, which is how I also discovered we were compiling with no warnings enabled.)