Bug 429408 - kde-open5 changes case of argument
Summary: kde-open5 changes case of argument
Status: CONFIRMED
Alias: None
Product: kde-cli-tools
Classification: Plasma
Component: general (show other bugs)
Version: 5.24.5
Platform: Manjaro Linux
: NOR normal
Target Milestone: ---
Assignee: Aleix Pol
URL: https://casenet.us/
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2020-11-20 18:00 UTC by Thomas Borowski
Modified: 2022-12-08 11:58 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Borowski 2020-11-20 18:00:08 UTC
SUMMARY

Calling

  kde-open5 'thunderlink://messageid=e4b0c66f-07c8-453d-abd7-97e416ec7b56@Spark' 

results in the error

  Couldn't find an email message for ThunderLink
  thunderlink://messageid=e4b0c66f-07c8-453d-abd7-97e416ec7b56@spark

Note that the 'S' in 'Spark' at the end of the argument is lowercase, not uppercase as it was passed. Apparently kde-open5 converts the argument to lowercase, resulting in the message ID passed to Thunderlink not being valid.

Passing an all-lowercase argument works as expected (Thunderbird opens the corresponding message).

kde-open5 should not change the case of the argument which it was passed but rather pass it on as-is.

Here's the contents of the corresponding desktop file:

[Desktop Entry]
Encoding=UTF-8
Name=Thunderlink Opener
Comment=Open specific Message-ID Thunderbird
Exec=thunderbird -thunderlink %u
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=thunderbird
Categories=Application;Network;Email;
MimeType=x-scheme-handler/thunderlink;
StartupNotify=true
NoDisplay=true



SOFTWARE/OS VERSIONS
Operating System: Kubuntu 20.04
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-54-generic
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6300U CPU @ 2.40GHz
Memory: 15,5 GiB of RAM
Comment 1 Casenet 2021-11-11 10:52:19 UTC
*** Removed by KDE Sysadmin for violation of the KDE Community Code of Conduct ***
Comment 2 Thomas Borowski 2021-11-11 11:00:36 UTC
(In reply to Casenet from comment #1)
> Depending on the used android keyboard you get the following reactions when
> writing uppercase - https://casenet.us/
> - Gboard: The Windows system usually reacts with the typical alert-sound
> when I press the shift key on the android keyboard to write uppercase. The
> transmission of the uppercase character works so far, dispite the
> windows-alert-sound.
> - Gboard: Uppercase characters appear lowercase in a RDP session
> - SwiftKey: Works as expected when not in RDP
> - SwiftKey: Uppercase characters appear lowercase in a RDP session

I think you're talking about a completely unrelated error. This bug is regarding to the kde-open5 program under KDE Plasma and has nothing to do with Android, Gboard, Windows, RDP, etc.
Comment 3 Egon Willighagen 2022-03-05 07:48:13 UTC
I got here via this StackOverflow workaround for a problem where Slack does not open all workspaces. The SO flow suggests the same upper/lower rewrite by KDE as a suspect. Here is some data from my machine just now (for privacy I use fake codes, like WORKSPACEID, xxx, YYYY, and zzz, of course with upper/lower casing exact):

    /bin/sh /usr/bin/xdg-open slack://WORKSPACEID/magic-login/xxxx/YYYY/magic-login/zzz-zzzzz-zzzzzzzzz
    kde-open5 slack://WORKSPACEID/magic-login/xxxx/YYYY/magic-login/zzz-zzzzz-zzzzzzzzz
    /usr/lib/slack/slack --enable-crashpad slack://workspaceid/magic-login/xxxx/YYYY/magic-login/zzz-zzzzz-zzzzzzzzz

I hope you trust my translation of my observation, but I can confirm that WORKSPACEID goed into kde-open5 as upper case, but is converted to lower case when passed to the `/usr/lib/slack/slack` application. And Slack seems to be case sensitive as suggested in the SO post: if I upper case back the WORKSPACEID in the `/usr/lib/slack/slack` call, then it opens properly.

* Slack 4.23.0
* kde-open5/kioclient 5.20.5
Comment 4 Levon Avagyan 2022-06-10 07:45:45 UTC
(In reply to Egon Willighagen from comment #3)
> I got here via this StackOverflow workaround for a problem where Slack does
> not open all workspaces. The SO flow suggests the same upper/lower rewrite
> by KDE as a suspect. Here is some data from my machine just now (for privacy
> I use fake codes, like WORKSPACEID, xxx, YYYY, and zzz, of course with
> upper/lower casing exact):
> 
>     /bin/sh /usr/bin/xdg-open
> slack://WORKSPACEID/magic-login/xxxx/YYYY/magic-login/zzz-zzzzz-zzzzzzzzz
>     kde-open5
> slack://WORKSPACEID/magic-login/xxxx/YYYY/magic-login/zzz-zzzzz-zzzzzzzzz
>     /usr/lib/slack/slack --enable-crashpad
> slack://workspaceid/magic-login/xxxx/YYYY/magic-login/zzz-zzzzz-zzzzzzzzz
> 
> I hope you trust my translation of my observation, but I can confirm that
> WORKSPACEID goed into kde-open5 as upper case, but is converted to lower
> case when passed to the `/usr/lib/slack/slack` application. And Slack seems
> to be case sensitive as suggested in the SO post: if I upper case back the
> WORKSPACEID in the `/usr/lib/slack/slack` call, then it opens properly.
> 
> * Slack 4.23.0
> * kde-open5/kioclient 5.20.5
Same problem with kde-open5/kioclient 5.24.90 and slack-4.26.1-0.1.fc21.x86_64.rpm
Comment 5 Egon Willighagen 2022-06-20 09:35:59 UTC
(In reply to Egon Willighagen from comment #3)
> I got here via this StackOverflow workaround for a problem where Slack does

SO link: https://stackoverflow.com/questions/70867064/signing-into-slack-desktop-not-working-on-4-23-0-64-bit-ubuntu/71062113#71062113

The approach to get the URLs is basically:

```shell
while sleep .1; do ps aux | grep slack | grep -v grep | grep magic; done
```

Can I just say this status of this bug should not be mere NORMAL but actually is a data corruption bug? Maybe not one of the severest, but annoyingly annoying.
Comment 6 Connor Schunk 2022-06-21 20:11:54 UTC
I'm not extremely familiar with the inner workings of Qt, but encountered this problem and decided to dig into it a bit in hopes of helping this bug get resolved. From what I can tell from the code kde-open5 seems to use (https://invent.kde.org/plasma/kde-cli-tools/-/blob/master/kioclient/kioclient.cpp#L235), QURL is involved (https://invent.kde.org/plasma/kde-cli-tools/-/blob/master/kioclient/urlinfo.h).

In QUrl (https://code.woboq.org/qt5/qtbase/src/corelib/io/qurl.cpp.html), I notice "nameprepping" and RFCs related to normalization are mentioned a few times, e.g.
>  Note that the case folding rules in \l{RFC 3491}{Nameprep}, which QUrl conforms to, require host names to always be converted to lower case, regardless of the Qt::FormattingOptions used

If I had to guess (with my limited understanding), I would assume the problem lies in the call to setHost, which in turn calls qt_ACE_do (https://code.woboq.org/qt5/qtbase/src/corelib/io/qurl.cpp.html#1365) - the normalization to lowercase probably lies somewhere in that chain.
Comment 7 kde 2022-07-07 00:39:33 UTC
https://code.woboq.org/qt5/qtbase/src/corelib/io/qurlidna.cpp.html#2536

There's your root cause. Bitwise OR of an ASCII character with 0x20 results in a change to lower case. This appears to be taking place in a unicode-to-ASCII conversion, which seems to be erroneously converting to lower case as a matter of course. The previously cited RFC, 3490/3491, obsoleted by 5890/5891, does make mention of lower case conversions, but strictly in the context of generating unique DNS labels for hostnames. 

Relevant:
https://www.rfc-editor.org/rfc/rfc5890
Comment 8 Joe 2022-11-09 02:30:41 UTC
Just wanted to say I came across this the other day and as Egon so nicely put it, it was "annoyingly annoying".  I ended up just doing things in Firefox to make signing into Slack work.
Comment 9 CyberKitsune 2022-12-06 21:32:05 UTC
+1 on seeing this happen with slack, KDE 2.26.4 and Qt 5.15.7

Judging by comment #7 would this actually be a Qt bug? Should it be worked around by kioclient or would we need to report and wait on a fix from Qt?
Comment 10 Oded Arbel 2022-12-08 11:58:40 UTC
I have the same issue with Slack - using "Open in desktop app" from the website running under Chrome, results in kde5-open being called and mangling the authority section of the URL.

(In reply to kde from comment #7)
> which seems to be erroneously converting to
> lower case as a matter of course. The previously cited RFC, 3490/3491,
> obsoleted by 5890/5891, does make mention of lower case conversions, but
> strictly in the context of generating unique DNS labels for hostnames. 

I believe the correct RFC for QURL implementations - in this case - is RFC 3986: URI Generic Syntax, where section 3.2.2 says: "The host subcomponent is case-insensitive". Granted that a reading of the spec to mean "fold everything to lowercase" is reaching a bit, but as per RFC 1122, p1.2.2 - receivers should accept lowercased host names.

According to discussions with Slack support, they are aware of this issue -which depending on how you look at it, is either KDE doing unexpected things, or Slack not complying with RFC 3986 - even though there's no way to know that because they don't have a public bug tracker. The also suggested a workaround: Apparently if you launch the `slack://...` URL from Firefox, it works fine: the URL isn't mangled.

I'm not sure what Firefox uses instead of kde5-open, but looking at the code for xdg-open, I can see that it has code to open flatpak apps that uses a dbus call, and in that case no case folding is happening and the application is launched successfully - event if the app is not a flatpak app. For example - the following command launches the DEB installed Slack on my system:

gdbus call --session --dest org.freedesktop.portal.Desktop --object-path /org/freedesktop/portal/desktop --method org.freedesktop.portal.OpenURI.OpenURI "" "slack://MAGICTOKEN/magic-login/id-id-id-id-id-id-id-id-id-id-id-id-id-id-id-id-id-id-id-id" {}

This call is handled by the xdg-desktop-portal process. Also, it may only work because Firefox is running in a snap?