| Summary: | kde-open5 changes case of argument | ||
|---|---|---|---|
| Product: | [Plasma] kde-cli-tools | Reporter: | Thomas Borowski <mail+kdebugs> |
| Component: | general | Assignee: | 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
*** 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 |