Bug 429408

Summary: kde-open5 changes case of argument
Product: [Plasma] kde-cli-tools Reporter: Thomas Borowski <mail+kdebugs>
Component: generalAssignee: Aleix Pol <aleixpol>
Status: CONFIRMED ---    
Severity: normal CC: casenet.us, egon.willighagen, ender8282, francescortiz, kde, kde, leledumbo_cool, levon.avagyan, me, me, nico.kruber, noga.dany, pia, rafaeln.dev, root, sokann
Priority: NOR Keywords: accessibility
Version: 5.24.5   
Target Milestone: ---   
Platform: Manjaro   
OS: Linux   
URL: https://casenet.us/
Latest Commit: Version Fixed In:

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