Bug 429408

*** Removed by KDE Sysadmin for violation of the KDE Community Code of Conduct ***

(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.

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

(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

(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.

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.

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

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.

+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?

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?

I also had this problem.