Bug 409518 - Visiting Fonts KCM changes antialliasing settings without warning
Summary: Visiting Fonts KCM changes antialliasing settings without warning
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_fonts (show other bugs)
Version: 5.16.3
Platform: Arch Linux Linux
: VHI major
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
: 409374 409793 410072 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-07-05 09:44 UTC by Matej Mrenica
Modified: 2019-07-28 08:25 UTC (History)
18 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.16.4


Attachments
fonts.conf; (1.05 KB, text/plain)
2019-07-12 15:23 UTC, postix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matej Mrenica 2019-07-05 09:44:25 UTC
STEPS TO REPRODUCE
1. Open Fonts KCM 
2. Open any other KCM
3. Go back to Fonts KCM

OBSERVED RESULT
Anti-aliasing settings are changed to: Ignore between 0 and 99 
After re-login antialiasing will be turned off.

EXPECTED RESULT
Settings don't change on their own.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.16.2
KDE Frameworks Version: 5.59
Qt Version: 5.13.0
Comment 1 Gianluca Pettinello 2019-07-07 06:31:19 UTC
Same for me
Comment 2 Bhushan Shah 2019-07-09 07:12:50 UTC
Can you provide ~/.config/kdeglobals and ~/.config/kcmfontrc files?
Comment 3 Matej Mrenica 2019-07-09 07:48:27 UTC
https://pastebin.com/a8zYh3y7 and https://pastebin.com/55bjLyTi
Comment 4 Bhushan Shah 2019-07-09 07:55:22 UTC
can you also pastebin ~/.config/fontconfig/fonts.conf?
Comment 5 Matej Mrenica 2019-07-09 08:06:39 UTC
(In reply to Bhushan Shah from comment #4)
> can you also pastebin ~/.config/fontconfig/fonts.conf?

I don't have this one.
Comment 6 Christopher 2019-07-10 22:54:42 UTC
Also happens to me randomly, this is annoying, I hope it will get fixed soon 

(・ω・`)
Comment 7 shscs911 2019-07-11 05:10:24 UTC
Happens to me even without opening `Font Settings`.
Comment 8 Matej Mrenica 2019-07-11 05:13:51 UTC
(In reply to shscs911 from comment #7)
> Happens to me even without opening `Font Settings`.

How does it happen for you then?
Comment 9 shscs911 2019-07-11 05:54:11 UTC
(In reply to mthw0 from comment #8)

> How does it happen for you then?

It happened when I was changing Splash Screens and re-logined. All the fonts were non anti-aliased including the notifications. After unchecking `Exclude range 0-99` and re-login, it was back to normal. After a shutdown and fresh start, everything was normal including notification fonts, but in the middle of browsing in Firefox it changed. One tab was normal, but the next tab onwards, fonts were non anti-aliased. I had recently installed and removed Deepin DE and found some leftover config in `~/.config/fontconfig/conf.d/`. Is it somehow related? Sorry for the rant.
Comment 10 postix 2019-07-12 15:23:54 UTC
Created attachment 121483 [details]
fonts.conf;

There are several <match target="font"> with different antialiasing settings. I suspect that the font config file generating got broken.
Comment 11 postix 2019-07-12 15:24:49 UTC
I can fully confirm mthw0's and shscs911's descriptions. 

#### System
Operating System: Manjaro Linux 
KDE Plasma Version: 5.16.2
KDE Frameworks Version: 5.59.0
Qt Version: 5.13.0
Kernel Version: 5.1.16-1-MANJARO
Comment 12 Matej Mrenica 2019-07-12 18:06:50 UTC
Since nobody mentioned this, this issue doesn't seem to exist on Wayland.
Comment 13 Patrick Silva 2019-07-14 23:04:11 UTC
*** Bug 409793 has been marked as a duplicate of this bug. ***
Comment 14 petrk 2019-07-17 04:07:32 UTC
I'm affected unfortunately. Happens when switching to and from "font management".

There's also some other trigger because I had to look at awful kana when I opened Audacious this morning.
Comment 15 petrk 2019-07-17 04:08:50 UTC
"Skip antialiasing for range" 0-99 toggles itself.
Comment 16 Nate Graham 2019-07-21 21:02:33 UTC
*** Bug 409374 has been marked as a duplicate of this bug. ***
Comment 17 Nate Graham 2019-07-21 21:07:27 UTC
I suspect this broke with https://cgit.kde.org/plasma-desktop.git/commit/?id=08ec9a036bf5b3ee102938ad332f624adc1060b9

Bhushan, could you take a look?
Comment 18 Nate Graham 2019-07-21 22:55:56 UTC
*** Bug 410072 has been marked as a duplicate of this bug. ***
Comment 19 Fabian Vogt 2019-07-23 11:06:40 UTC
I still cannot reproduce this bug on openSUSE TW, and I'm trying quite hard.

I noticed that all reports about this bug seem to come from users of Arch or derivatives, so maybe it's something with compile options or other library versions.

Can someone build it with -fsanitize=address and/or run with valgrind?
I think that we're chasing some uninitialized variables.
Comment 20 Matej Mrenica 2019-07-23 11:37:41 UTC
I (OP) have checked and I don't seem to have this problem anymore. 
I remember deleting "~/.config/kcmfonts" but I am not sure if it is what fixed this.
Comment 21 Antonio Rojas 2019-07-23 13:33:53 UTC
I can reproduce, investigating - it's unrelated to 08ec9a036bf5b3ee102938ad332f624adc1060b9
Comment 22 Filip Fila 2019-07-23 13:47:51 UTC
[Manjaro] I also experienced this.

It was triggered by changing the font and then it wouldn't stop happening.

I deleted fonts.conf in the home dir and generated it with qt5ct. Haven't touched the Fonts kcm since and have been left alone by the bug.
Comment 23 Antonio Rojas 2019-07-23 23:11:35 UTC
Alright, found the issue. This is indeed a (very tricky) case of uninitialized variables. The problem is in PreviewImageProvider::requestImage, which saves the
Comment 24 Antonio Rojas 2019-07-23 23:16:18 UTC
(In reply to Antonio Rojas from comment #23)
Alright, found the issue. This is indeed a (very tricky) case of uninitialized variables. The problem is in PreviewImageProvider::requestImage, which saves the xft exclude range to temporary variables oldStart, oldEnd which are not initialized, then sets the exclude range to (0,0) to perform some computations, and finally restores the old exclude range from the oldStart, oldEnd variables.

The issue comes up when the original exclude range is (0,0), in which case xft.getExcludeRange does not assign any value to the variables. So, at the end, the exclude range was set to whatever random values these variables were storing.

Fixed in https://phabricator.kde.org/D22707 by properly initializing the variables.
Comment 25 Josh Freeno 2019-07-24 00:11:38 UTC
I have still got this problem as of today. It has done several times today already.

Operating System: Arch Linux 
KDE Plasma Version: 5.16.3
KDE Frameworks Version: 5.60.0
Qt Version: 5.13.0
Kernel Version: 5.2.2-arch1-1-ARCH
OS Type: 64-bit
Comment 26 Nate Graham 2019-07-24 01:58:25 UTC
Thanks so much Antonio!
Comment 27 Antonio Rojas 2019-07-24 06:03:57 UTC
Git commit b0f1d6620d78235e5b85defab880d68129f7a4e9 by Antonio Rojas.
Committed on 24/07/2019 at 06:03.
Pushed by arojas into branch 'Plasma/5.16'.

Properly initialize oldStart and oldEnd in PreviewImageProvider::requestImage

Otherwise they may not get assigned any value if the xft exclude range is (0,0), which will make them write random values to the xft exclude range later.

Differential Revision: https://phabricator.kde.org/D22707

M  +1    -1    kcms/fonts/previewimageprovider.cpp

https://commits.kde.org/plasma-desktop/b0f1d6620d78235e5b85defab880d68129f7a4e9
Comment 28 Michael 2019-07-24 09:55:30 UTC
I can confirm, the issue is fixed for me (Plasma 5.16.3, Frameworks 5.60.0, Qt 5.13.0, 5.2.2-arch1-1).
Thank you.