Created attachment 129135 [details] firewalld garbled info SUMMARY While hovering the mouse over icons in the system tray, the information is not displayed correctly, is all garbled. It does no happen for everything, so far i've seen it happen for firewalld applet and qibitorrent. STEPS TO REPRODUCE 1. hover the mouse over icons in the system tray 2. if the icons displays some information it will be garbled. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.6.14/opensuse tumbleweed KDE Plasma Version: 5.19.80 KDE Frameworks Version: 5.71.0 Qt Version: 5.15.0
Regression introduced in: https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/6
So we have a few options here: - Revert https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/6 and allow applets to use HTML - Adjust the API so that apps can *optionally* use rich text and HTML in the tooltip, but keep the default as plain text - Fix the firewall applet to respect the documented behavior and stop using HTML. Is this a first-party applet, or a 3rd-party one? There isn't anything for the System Tray to do here; moving accordingly.
Both affected apps are 3rd-party, using SNI (not an applet/plasmoid). Several apps are using HTML in tooltips. System tray uses PlasmaCore.ToolTipArea and relays on "textFormat: Text.AutoText", for SNI icons - Text.PlainText is not enough.
> "textFormat: Text.AutoText", has been repeatedly problematic with regards to security. It'll process <img="http://..." and for us loading any network request without user expectation is frowned upon.
Perhaps we could use Text.StyledText instead? That would allow applets to use some basic styling without the performance and security issues associated with Text.AutoText. Or does StyledText still allow external <a> and <img> HTML, or just for local resources? The documentation isn't totally clear on the matter.
Just before couple minutes I reported Bug 423125 what happens for Clementine.
*** Bug 423125 has been marked as a duplicate of this bug. ***
(In reply to David Edmundson from comment #4) > > "textFormat: Text.AutoText", > > has been repeatedly problematic with regards to security. > > It'll process <img="http://..." and for us loading any network request > without user expectation is frowned upon. Hmm, I don't think it is such a big problem. App can send unexpected network requests anyway, one more in tooltip should not make a difference. From the other side loading anything from the Internet can be risky, both for security and privacy reasons. I wouldn't worry about performance, even if Text.AutoText is slow the impact is low. Having Text.StyledText explicitly is probably the best option. The best would be to have something like Text.RestrictedStyledText which would not allow external resources, but there is nothing like that :) We need to allow HTML in tooltip anyway - it is already used by several apps. I assume it is also supported by other DMs (is it? Gnome?).
I also have a bunch of programs (mostly Qt-but-not-KF5-based) which use some HTML tags in the tooltip and are now horrible to read xD I say either filter out img="http..." tags, or at least allow the most common styling ones, like <b> and <i> (and <br />, very much needed!). Thanks!
So what do folks think we should do here? Revert the change and allow HTML in tooltips again to un-break apps, and then change the documentation to reflect reality? Or Tell all the apps they they have to change to follow what the documentatio says (which is now enforced by reality). Option 1. re-introduces some potential security issues from malicious HTML in tooltips, while option 2 isn't very nice to apps.
*** Bug 423852 has been marked as a duplicate of this bug. ***
qBittorent tooltip is looking nice :) https://imgur.com/whqUoL2
>Or Tell all the apps they they have to change to follow what the documentatio says (which is now enforced by reality). We will do this. We have specifications for a reason. firewalld and qbittorrent have bugs and are not spec compliant, they're the ones that need fixing Jan and Tony can you file bugs respectively and link here. If there is any pushback from the clients please link me.
Actually there is an open bug already: https://github.com/qbittorrent/qBittorrent/issues/13030
(In reply to David Edmundson from comment #13) > >Or Tell all the apps they they have to change to follow what the documentatio says (which is now enforced by reality). > > We will do this. We have specifications for a reason. I'm sorry, but to be clear, *what* will you be doing? Supporting the HTML subset mentioned in the spec you linked https://specifications.freedesktop.org/notification-spec/latest/ar01s04.html ? I see this has been "resolved" as "downstream", which sounds like it's been decided to ignore all HTML and be done with it...
I've just realised I'm talking about different specifications. These are SNIs are and not notifications. My apologies. We can rediscuss this. Our relevant specification is this one: https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierItem/
(In reply to David Edmundson from comment #16) > I've just realised I'm talking about different specifications. > These are SNIs are and not notifications. Ah, phew... Then I guess https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/Markup/ makes it clear that the most basic tags like <b> should be supported. I'd add that <br> (and its variations) should be supported too. For the record, *notifications* are not broken, as something like: kdialog --passivepopup "This is a <b>TEST</b>." work fine =) Cheers!
*** Bug 424477 has been marked as a duplicate of this bug. ***
(In reply to JanKusanagi from comment #17) > Ah, phew... Then I guess > https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/Markup/ > makes it clear that the most basic tags like <b> should be supported. I'd > add that <br> (and its variations) should be supported too. The spec mentions markup being allowed in the tooltip text/subtitle, not the title. I read this as markup is not allowed in the title
Relevant upstream report: https://github.com/firewalld/firewalld/issues/668
(In reply to Nicolas Fella from comment #19) > The spec mentions markup being allowed in the tooltip text/subtitle, not the > title. I read this as markup is not allowed in the title I don't have a problem with that =)
(In reply to Nicolas Fella from comment #19) > The spec mentions markup being allowed in the tooltip text/subtitle, not the > title. I read this as markup is not allowed in the title Now I've realized that in programs like KTorrent and Konversation, which use both fields, the Title looks like the only part of the tooltip in the programs I use that have this HTML problem. Looks like those programs are only using the Title field. Apparently Qt5's QSystemTrayIcon's setToolTip() only sets the title field. I realize this is not Plasma's problem "per se", but since it might be breaking a bunch of programs, maybe have some kind of "if title has HTML but there's no descriptive text, interpret title as descriptive text, and program's name as title" or something like that.
What about Clementine, which displays in ToolTip cover related with plying song, just using HTML. Will be this possible with new suggested solution?
(In reply to JanKusanagi from comment #22) Apparently Qt5's QSystemTrayIcon's setToolTip() only sets the title field. I > realize this is not Plasma's problem "per se", but since it might be > breaking a bunch of programs, maybe have some kind of "if title has HTML but > there's no descriptive text, interpret title as descriptive text, and > program's name as title" or something like that. That sounds unexpected and potentially dangerous so I would object to such a workaround
(In reply to Piotr Mierzwinski from comment #23) > What about Clementine, which displays in ToolTip cover related with plying > song, just using HTML. Will be this possible with new suggested solution? If Clementine wants to have HTML in its tooltip it can use the tooltip text property for that already
(In reply to Nicolas Fella from comment #24) > That sounds unexpected and potentially dangerous so I would object to such a > workaround Could the plasma-integration, or whatever it is that makes Qt programs use KF5 filepickers and such, maybe "intervene" in how Qt5's QSystemTrayIcon creates the SNI's and behaves in regards to tooltips? Then it could transform those into tooltips with maybe no "title", and the contents moved to the "sub-title" field? Then it could render as Qt programs have come to expect... I want to believe the solution to this bug is not "all those programs are broken until Qt6, or until they reimplement their SNI's some other way" or something like that...
Same issue here.
You should fix QSystemTray first, patch every possible distro and only THEN break the UX when the impact is minimal. I do not see how the issue is "resolved" for now
Technically you broke the UX for hundreds of thousands of people and did nothing to fix it. That's what you did. And you expect KDE Plasma to be popular at this rate…
The status says it's fixed but it's not: https://i.imgur.com/JjVdiQl.png
(In reply to Nicolas Fella from comment #25) > (In reply to Piotr Mierzwinski from comment #23) > > What about Clementine, which displays in ToolTip cover related with plying > > song, just using HTML. Will be this possible with new suggested solution? > > If Clementine wants to have HTML in its tooltip it can use the tooltip text > property for that already Is it possible that 'tooltip text property' will display cover of playing song or any picture? If yes, then no problem.
qBittorrеnt team fixed this problem in 4.3.0.
In Clementine fixed in version 1.4rc2 Cover art is no longer displayed.
*** Bug 428597 has been marked as a duplicate of this bug. ***
(In reply to Nicolas Fella from comment #35) > *** Bug 428597 has been marked as a duplicate of this bug. *** Please, note that the Bug 422616 that affect firewalld applet, qibitorrent and Clementine was fixed by the teams of qibitorrent and Clementine only. No one was assigned to take care of this bug in firewalld in it remains.
(In reply to Miguel Rozsas from comment #36) > (In reply to Nicolas Fella from comment #35) > > *** Bug 428597 has been marked as a duplicate of this bug. *** > > Please, note that the Bug 422616 that affect firewalld applet, qibitorrent > and Clementine was fixed by the teams of qibitorrent and Clementine only. > No one was assigned to take care of this bug in firewalld in it remains. Regarding firewalld, one of the openSUSE guys announced a fix some time ago: https://github.com/firewalld/firewalld/issues/668#issuecomment-668183971
According to this: https://github.com/firewalld/firewalld/commit/69489661ec8eca1c2ed3c6159024c271e7e6eb2b it was fixed on 20 Apr. Any idea how long it takes to be available to the users ?
It depends on the distribution you are using. On Arch we get it as soon as it was released.
It's all up to the firewalld developers deciding when to make releases, and distros deciding when to ship those releases to users. Best-case scenario: they already made a release and you're using a rolling release distro, so the fix is already available. Worst-case Scenario: they haven't made a release yet and you're using Debian Stable, which means you will probably get the fix in 1-3 years.
Nah...I am using opensuse tumbleweed (rolling release) up to date (installed: 20210804) and currently it has firewall-applet-0.9.3-3.3.noarch so I am wondering why opensuse has not it in the factory already....
(In reply to Miguel Rozsas from comment #41) > Nah...I am using opensuse tumbleweed (rolling release) up to date > (installed: 20210804) and currently it has firewall-applet-0.9.3-3.3.noarch > so I am wondering why opensuse has not it in the factory already.... I wonder so too. The downstream report is https://bugzilla.opensuse.org/show_bug.cgi?id=1184683.