Bug 439661 - Don't allow downloading 3rd-party Plasma/icon/etc theme that names itself "default" and/or duplicates metadata from the default theme, which will override the the default thing with no clear GUI method to fix it
Summary: Don't allow downloading 3rd-party Plasma/icon/etc theme that names itself "de...
Status: CONFIRMED
Alias: None
Product: frameworks-knewstuff
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.90.0
Platform: Other Linux
: HI normal
Target Milestone: ---
Assignee: Dan Leinir Turthra Jensen
URL:
Keywords: usability
: 440895 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-07-09 01:33 UTC by Nate Graham
Modified: 2022-02-11 19:25 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2021-07-09 01:33:14 UTC 
If you happen to download a GHNS theme for Plasma and the theme's folder name is "default", you will wind up with a folder like ~/.local/share/plasma/desktoptheme/default. This will override the system-provided Plasma theme, which will *disappear* from the Plasma theme KCM! Thus if you were using Breeze before, you will have the experience of your Plasma theme abruptly changing to something else, and the option to go back to Breeze has vanished. This is extremely unnerving.

It's also possible for this to happen if a theme changes its folder name to "default" in an update, which happened to me today.

Arguably this situation is caused by a bug in the 3rd-party theme, as themes really shouldn't name themselves "default". But it also shouldn't be possible for 3rd-party themes to break the system like this.

I am somewhat embarrassed to admit that I recently closed a bug reporting this same issue as an upstream issue with the theme itself, but after experiencing it myself, I have to agree with the bug reporter that it shouldn't be possible for a 3rd-party theme to break the system in this way. I can't find the bug report though, which is why I'm now filing a new one.
Comment 1 Nate Graham 2021-08-03 03:22:00 UTC 
Raising to VHI because IMO this is one of those "throw the computer out the window" bugs that will cause regular people to abandon our software because it will be baffling and mystifying and frustrating and they will have no hope of troubleshooting it.
Comment 2 Nate Graham 2021-08-12 16:04:27 UTC 
*** Bug 440895 has been marked as a duplicate of this bug. ***
Comment 3 Bharadwaj Raju 2022-01-22 07:55:50 UTC 
I wonder where it would be best to fix this. Should we check theme files in GHNS? Or just refuse to use a "default" folder if it's in ~/.local/share?

The first one would make it so theme authors get to know this when their users report that they can't install their themes, but won't fix the problem for users who're already affected.

The second one would fix it for all users, but their themes would silently stop working, and theme authors won't get notified that there is a problem.

We could combine the two, but even then the issue of their themes silently ceasing to work is still there.
Comment 4 Nate Graham 2022-02-11 19:25:55 UTC 
I think we should prevent it from happening in two places:
1. GHNS shouldn't let you download a mis-configured theme like this. It could even email the author when someone tries. The author would get approximately four hundred thousand emails when something like this happens, so they would fix it very quickly!
2. The individual System Settings KCMs shouldn't let you manually apply a misconfigured theme like this.

Moving to GHNS for now as that would fix 99% of the issue.