wayk:// links opened via chrome (and chrome-ish browsers) in Linux result in chaos

Hi,

As you have noticed, trying to use invalid URLs leads to invalid results. Wayk Now uses the wayk.link URL to fetch a JSON value from key-value storage, and connect to it. My guess is you've pointed Wayk Now to an invalid URL and we do not seem to be catching the error early enough, resulting in a garbage destination address.

We'll review this portion of code to handle invalid URLs better. In the meantime, please try using this feature as intended.

Best regards,

I am not meaning wayk.link, but rather wayk://xxxxxx urls like in the dashboard. they dont work for my own 2 PCs currently registered with wayk and I just tried some stuff to find a system, also not sure whether for example 000009 is a valid one since that at least gets attempted a connection.

see attachment. the wayk url from there is already failing.

Hello

I did try reproducing this on an Ubuntu 18.04 system with both Chrome and Firefox, but it seemed to work well for me - both with a URL from the dashboard, and some "made up" URLs in a test html page.

XDG should pass the URL to Wayk Now as the first argument to the program. Can you try passing the URL directly, and see if it works? This will rule out an issue somewhere between the browser and Wayk Now. For example, running:

/usr/bin/wayk-now wayk://123456

On my machine launches Wayk Now (or switches to the already running instance) and tries to connect to 123456.

Thanks and kind regards,

okay this is kinda weird. are there ways to debug that or get a hold of wtf is happening? it just seems kinda weird.

Hello

We need to know first if the address is getting passed properly to Wayk Now, that can be determined by trying what I suggested in my previous post (manually passing the link to the application on the command line).

If the ID is still getting resolved in a strange way when the link is passed directly, it seems likely that resolution of the Wayk ID is failing (or not even being tried) and the app is trying to resolve the ID as an IP address, which would lead to strange results. That could occur for a few reasons, though any way it would be a bug. If you could set the application log level to DEBUG and reproduce the issue, then send us the log file from ~/.config/Wayk/logs/WaykNog.log, we would be able to troubleshoot that further.

Thanks and kind regards,

for some reason apparently in firefox and in the terminal it seems to get through (maybe because it doesnt go extra passes like xdg-whatever and just uses wayk apparently directly, no idea.

but interestingly, I while I dont get a lot of messages, neither in debug nor even trace mode the messages do differ slightly:

Chrome:

[2020-01-26] [09:24:29:284] [16837:16837] [DEBUG][NowSingleton] - successfully connected to socket (a client instance is already running)
[2020-01-26] [09:24:29:284] [16837:16837] [WARN][NowSingleton] - sendmsg failed to send completely (expected 56 bytes, sent 46 bytes


Firefox/cmd:

[2020-01-26] [09:25:47:859] [16894:16894] [DEBUG][NowSingleton] - successfully connected to socket (a client instance is already running)
[2020-01-26] [09:25:47:859] [16894:16894] [WARN][NowSingleton] - sendmsg failed to send completely (expected 56 bytes, sent 40 bytes


so something is definitely different.

when using xdg-open in the terminal however I also get the death maybe because how it chains stuff around (seems it tries to pass stuff along depending on a few things like which GUI is used, in my case KDE)

this happens when I do that:

my1@my1-qb:/var/log$ xdg-open wayk://(my-id)
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "wayk"
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "wayk"
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "wayk"
kf5.kio.core: "preferred service for x-scheme-handler/wayk" "wayk-now"
my1@my1-qb:/var/log$ An error occurred during initialization (-1006).


after that basically immediately wayk goes to say that the target cant be reached and the textbox is filled with a weird IP.

so apparently xdg-open at least is a script so one can read what it does, and in KDE5 it apparently tries kde-open5, which in bash directly throw the same fun results. apparently it tries to read it as a hex and convert that to an IP at least with my real ID, but when it starts with a zero (see top post) it seems to try octal and fails if a 9 is involved.

guess this is kinda weird and I look around where to report this.

Hello

A little background here: the .deb creates a .desktop entry that looks something like that:

So we register ourselves as handling "wayk://" links and accept the full URL as the first argument to the application.

In the case that Wayk Now is already running, we pass the URL to the existing instance using IPC. That is the log line that says something like "expected 56 bytes, sent 46 bytes". So yes: it looks like whatever xdg-open is passing to us is different somehow.

This just means that another instance of Wayk Now was already running; it's an expected output in this case and doesn't indicate a true error.

It does appear that things are working differently under KDE - as you say, xdg-open is just a wrapper script. We will work on debugging this on a KDE system - I will post back here once I have some information on that, although I can't specify any timeline. If you work out the differences in the meantime we would be happy to incorporate any needed changes.

Thanks and kind regards,

okay, the interesting part is also that using kde-open (note that there is no 5 here) does work with wayk correctly, but apparently in the 5 version they do that IP conversion. apparently an IP can "legally" be represented by a number, be it hex octal or whatever and some commands do auto convert when they expect an IP/host, but apparently kde-open5 seems to too.

one dumb (potential, I cant say for sure) fix would be not just using numbers but for example whatever like wayk://connect/xxxxxx or whatever, which could also open up wayk:// for more actions in the future

Hello again

In that case it sounds like a bug in kde-open5. They must be interpreting the fact that because the host part of the URL starts with a numeral, it should be parsed as an IP address. It is a valid URL but I can see why there would be confusion in the client - although this is the first instance we've heard of it.

We will address this in a future update.

Thanks for the troubleshooting effort and kind regards,