SUMMARY ...for no reason. Breeze Light color scheme, since Plasma 5.17 Beta.
In which apps? Can you reproduce with the UI controls visible in the window that appears when you run `grk3-widget-factory?`
Yes, here: https://gfycat.com/victoriousdistantkissingbug I am not clicking anywhere, just moving my mouse. Also in Firefox, e.g. on this very page.
Weird, cannot reproduce with Breeze Light or any other color scheme. Does this happen for you with every color scheme, or just Breeze Light?
(In reply to Nate Graham from comment #3) > Weird, cannot reproduce with Breeze Light or any other color scheme. > > Does this happen for you with every color scheme, or just Breeze Light? Every color scheme, downgrading fixes this issue and updating breaks it again. @Patrick Silva, do you have this issue too? I remember you using Plasma Beta on Arch Linux.
Thanks.
(In reply to mthw0 from comment #4) > @Patrick Silva, do you have this issue too? I remember you using Plasma Beta > on Arch Linux. Yes, it occurs when I hover over gtk radio buttons and checkboxes. I use breeze color scheme.
I also noticed that scrollbars in apps like Thunderbird turn black during app switching, which might be related/caused by the same thing.
I ca nreproduce this bug if I use the Arch package (5.16.90), or if I build from the tar at `https://download.kde.org/unstable/plasma/`. However, I can't reproduce it if I build from the git repo (checked with 5.17 branch, 5.16 branch, 5.16.90 tag). Perhaps there is some issue with the tars?
*** Bug 412258 has been marked as a duplicate of this bug. ***
Can also confirm that this happens in Firefox and other GTK places on Arch's kde-unstable packages for me, too.
*** Bug 412863 has been marked as a duplicate of this bug. ***
Would it be possible to find out what commit caused this problem and revert it until a better solution is discovered?
Just updated to Arch's final 5.17.0 packages, it is still there.
*** Bug 412988 has been marked as a duplicate of this bug. ***
*** Bug 413001 has been marked as a duplicate of this bug. ***
I notice that all the reports are from Arch. I wonder if there's something odd with their packaging or GTK version.
(In reply to Nate Graham from comment #16) > I notice that all the reports are from Arch. I wonder if there's something > odd with their packaging or GTK version. It's most likely not the GTK version, as no relevant code was changed from 3.24.11 (known good) to 3.24.12 (Arch's version). Additionally, I cannot reproduce it building 3.24.12 from source on openSUSE.
Created attachment 123229 [details] Checkboxes are black Same for me. Almost every site has black checkboxes with Breeze Dark Plasma Style Theme. Breeze Light looks like good
Hi, I've bisected the problem (hope https://github.com/KDE/breeze-gtk is correct repository). It is caused by commit 7b3d0777ea6c10dd430ed686434d3a4e2d072632.
I don't like behavior when DE (OS) override site behavior. Why DE setting is importantly then site settings?
(In reply to Webcapcha from comment #18) > Created attachment 123229 [details] > Checkboxes are black > > Same for me. Almost every site has black checkboxes with Breeze Dark Plasma > Style Theme. > > Breeze Light looks like good The original bug occurs in Breeze light too. Yours sounds unrelated. You might find this useful: https://stackoverflow.com/questions/51684455/firefox-default-colour-scheme-for-inputs-forms
Got same bug on the Fedora 30 with gtk3-3.24.11 (in Firefox).
*** Bug 413040 has been marked as a duplicate of this bug. ***
I have the same issue in Archlinux with Breeze light set in GNOME/GTK Style. It started with 5.17.
(In reply to Xwang from comment #24) > I have the same issue in Archlinux with Breeze light set in GNOME/GTK Style. > It started with 5.17. I forgot the issue happens in Firefox and Thunderbird which are the two GTK apps that I use.
Another Arch Linux user reporting in. Running Plasma with default settings (read: Breeze, with everything pristine and set to default) and after upgrading to 5.17.0-1 in Arch, programs that use GTK 2 and GTK 3 look wonky. Firefox and GIMP appear like this, with dark and bright elements mixed: https://imgur.com/5yYiFww https://imgur.com/kdhkdVi
(In reply to Martin Roth from comment #26) > Another Arch Linux user reporting in. Running Plasma with default settings > (read: Breeze, with everything pristine and set to default) and after > upgrading to 5.17.0-1 in Arch, programs that use GTK 2 and GTK 3 look wonky. > Firefox and GIMP appear like this, with dark and bright elements mixed: > > https://imgur.com/5yYiFww > https://imgur.com/kdhkdVi That's a separate issue (already known and being worked on).
(In reply to Nate Graham from comment #27) > (In reply to Martin Roth from comment #26) > > Another Arch Linux user reporting in. Running Plasma with default settings > > (read: Breeze, with everything pristine and set to default) and after > > upgrading to 5.17.0-1 in Arch, programs that use GTK 2 and GTK 3 look wonky. > > Firefox and GIMP appear like this, with dark and bright elements mixed: > > > > https://imgur.com/5yYiFww > > https://imgur.com/kdhkdVi > That's a separate issue (already known and being worked on). I wasn't sure whether to report this, or where. Thank you for the prompt and reassuring reply!
*** Bug 413132 has been marked as a duplicate of this bug. ***
*** Bug 413266 has been marked as a duplicate of this bug. ***
Created attachment 123415 [details] also affects radio buttons This also happens with radio buttons. Operating System: openSUSE Tumbleweed 20191018 KDE Plasma Version: 5.17.0 KDE Frameworks Version: 5.63.0 Qt Version: 5.13.1
Mousing over checkboxes in Plasma 5.17 on my system causes them to alternate between being solid white, solid blue with an inner grey square, solid blue with an inner white square, and solid grey: https://www.youtube.com/watch?v=BSqIES6wdfQ Operating System: Arch Linux KDE Plasma Version: 5.17.0 KDE Frameworks Version: 5.63.0 Qt Version: 5.13.1 Kernel Version: 5.3.7-arch1-1-ARCH OS Type: 64-bit Processors: 4 × Intel® Core™ i5-6600K CPU @ 3.50GHz Memory: 15.6 GiB of RAM GPU: GTX 1070 Nvidia driver version: 435.21
*** Bug 413336 has been marked as a duplicate of this bug. ***
FWIW I've been seeing this on openSUSE Tumbleweed since the distro-provided 5.17 upgrade, so this doesn't appear to be Arch-specific. An upstream bug report on GTK itself has been filed: https://gitlab.gnome.org/GNOME/gtk/issues/2217 We're investigating whether this is purely an upstream issue, or if there's anything we can do on our side. In the worst-case scenario where it turns out to be a GTK issue but nobody knows how to fix it or has any interest in doing so, we'll have to revert the change to dynamically re-color checkboxes and radio buttons. :(
I've seen this on Manjaro and KDE Neon.
Same problem here. Not sure if it was mentioned but you not even need to open an GTK3 aplication to reproduce this issue. On KDE Settings / GTK Application Style (preview) its possible to see it. Is there any workaround besides change de theme to default/Emacs? Operating System: Arch Linux KDE Plasma Version: 5.17.1 KDE Frameworks Version: 5.63.0 Qt Version: 5.13.1 Kernel Version: 5.3.7-arch1-2-ARCH OS Type: 64-bit Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz Memory: 15,5 GiB of RAM
There is currently no workaround. We're looking into reverting the change until the underlying GTK issue is fixed.
(In reply to Nate Graham from comment #37) > There is currently no workaround. We're looking into reverting the change > until the underlying GTK issue is fixed. Thank you Nate, wasn't sure since I saw on other threads ppl talking about downgrading gtk libs. For the time being IMO the best option is to use default theme on GTK application setting.
Git commit b1649126c8c6d1af746a8472939fcda40a260095 by Carson Black. Committed on 29/10/2019 at 00:26. Pushed by cblack into branch 'Plasma/5.17'. [GTK3] Revert checkbox recolouring Summary: This reverts the effects of commit 7b3d0777ea6c10dd430ed686434d3a4e2d072632 and some effects of commit 987f750ea16a6f82d29cd6504a69d93575c895d4, meaning that checkboxes and radiobuttons will no longer attempt to follow the colourscheme. This is necessary because the facilities used to recolour checkboxes are now glitchy in GTK and result in usability issues. See https://gitlab.gnome.org/GNOME/gtk/issues/2217 FIXED-IN: 5.17.2 Test Plan: Before: https://bugs.kde.org/show_bug.cgi?id=412078 After: {F7675941} Reviewers: #vdg, ngraham Reviewed By: #vdg, ngraham Subscribers: ngraham, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D24994 M +58 -34 src/gtk3/widgets/_checkboxes.scss M +8 -21 src/gtk3/widgets/_menus.scss https://commits.kde.org/breeze-gtk/b1649126c8c6d1af746a8472939fcda40a260095
(In reply to Joel Teixeira from comment #38) > For the time being IMO the best option is to use > default theme on GTK application setting. Thank you for the suggestion! I was seriously considering giving up Firefox for Chrome. The most annoying thing for me was not the faulty coloring but how much narrower the scroll bars were. That made web surfing much harder.
(In reply to Raul Laasner from comment #40) > (In reply to Joel Teixeira from comment #38) > Thank you for the suggestion! I was seriously considering giving up Firefox > for Chrome. The most annoying thing for me was not the faulty coloring but > how much narrower the scroll bars were. That made web surfing much harder. The same here Raul, I'm glad the suggestion helped.
(In reply to Carson Black from comment #39) > Git commit b1649126c8c6d1af746a8472939fcda40a260095 by Carson Black. > Committed on 29/10/2019 at 00:26. > Pushed by cblack into branch 'Plasma/5.17'. > > [GTK3] Revert checkbox recolouring > > Summary: > This reverts the effects of commit 7b3d0777ea6c10dd430ed686434d3a4e2d072632 > and some effects of commit 987f750ea16a6f82d29cd6504a69d93575c895d4, > meaning that checkboxes and radiobuttons will no longer attempt to follow > the colourscheme. > > This is necessary because the facilities used to recolour checkboxes are now > glitchy in GTK > and result in usability issues. See > https://gitlab.gnome.org/GNOME/gtk/issues/2217 > FIXED-IN: 5.17.2 > > Test Plan: > Before: https://bugs.kde.org/show_bug.cgi?id=412078 > After: {F7675941} > > Reviewers: #vdg, ngraham > > Reviewed By: #vdg, ngraham > > Subscribers: ngraham, plasma-devel > > Tags: #plasma > > Differential Revision: https://phabricator.kde.org/D24994 > > M +58 -34 src/gtk3/widgets/_checkboxes.scss > M +8 -21 src/gtk3/widgets/_menus.scss > > https://commits.kde.org/breeze-gtk/b1649126c8c6d1af746a8472939fcda40a260095 Will this ever be re-enabled?
Once the issue in gtk is fixed or a workaround is found.
Looks like the upstream issue is being fixed. See https://gitlab.gnome.org/GNOME/librsvg/issues/525 We'll investigate at which point we can bring this back!
(In reply to Nate Graham from comment #44) > Looks like the upstream issue is being fixed. See > https://gitlab.gnome.org/GNOME/librsvg/issues/525 Confirmed! > We'll investigate at which point we can bring this back! As it's now known what exactly the issue is, maybe it's possible to work around it effectively?
New/fixed version of librsvg has been released, so I guess this feature could go back in, right?
(In reply to mthw0 from comment #46) > New/fixed version of librsvg has been released, so I guess this feature > could go back in, right? It's already back in master. For other branches, I'd say it's up to the distro.
For clarity, please: can anyone confirm whether this issue was the cause of radio buttons entirely missing from Firefox e.g. as pictured below? Screenshot from 2019-11-01: https://bz-attachments.freebsd.org/attachment.cgi?id=208753
(In reply to Graham Perrin from comment #48) > For clarity, please: can anyone confirm whether this issue was the cause of > radio buttons entirely missing from Firefox e.g. as pictured below? > > Screenshot from 2019-11-01: > > https://bz-attachments.freebsd.org/attachment.cgi?id=208753 No, that's Bug 396889.
So this has started happening to me again since updating to Plasma 5.17.90, and now on 5.18.0. Anyone else? =)
This has appeared in PCLinuxOS since upgrading to 5.18.0 (and now 5.18.1) from 5.17.5.
(In reply to K.J. Petrie from comment #51) > This has appeared in PCLinuxOS since upgrading to 5.18.0 (and now 5.18.1) > from 5.17.5. What version of librsvg does PCLinuxOS have?
librsvg was updated to 2.46.4 in PCLinuxOS today.
Yes, so my reopening of the bug was invalid. I presume the other person's distro also hasn't upgraded that package, so I'm undoing my reopen though I won't change the reason because the original bug was fixed.
Mageia has librsvg-2.47.0 and this issue still reappeared with Plasma 5.18. What version of librsvg is required to fix this?
(In reply to JanKusanagi from comment #55) > Mageia has librsvg-2.47.0 and this issue still reappeared with Plasma 5.18. > > What version of librsvg is required to fix this? According to the upstream bug reported linked to in Comment 34, librsvg 2.46.4 was to contain the fix. (That's the version that I'm running, on openSUSE Tumbleweed, and I'm not experiencing the bug any more.) If you are seeing the problem with librsvg 2.47.0, then there may have been a regression, and so this should probably be reported on the upstream bug report.
Doesn't librsvg follow that odd/even numbering scheme for stable/development versions? In any case 2.47.0 is actually older than 2.46.4, so you probably want to ask the Mageia packagers a) why they ship a development version and b) why they don't update it to the latest version of that branch (2.47.3, 2.47.1 also has the fixes which are included in 2.46.4).
(In reply to Heiko Becker from comment #57) > In any case 2.47.0 is actually older than 2.46.4, so you probably want to > ask the Mageia packagers a) why they ship a development version and b) why > they don't update it to the latest version of that branch (2.47.3, 2.47.1 > also has the fixes which are included in 2.46.4). Ah, good to know, thanks! FTR, I'm talking about Mageia Cauldron, ie, the development branch, which would explain why the development version of librsvg is in use here. But I'll ask them to upgrade it to the latest 2.47. Thanks for the pointer =)
(In reply to Tristan Miller from comment #56) (In reply to Heiko Becker from comment #57) OK, so the Mageia folks have updated librsvg to 2.47.1 and I can confirm that with it, this issue is indeed gone =)