Bug 396813 - PlasmaComponents2 text fields have unreadable placeholder text with light themes (affects Kicker, KRunner, Widget Explorer...)
Summary: PlasmaComponents2 text fields have unreadable placeholder text with light the...
Status: RESOLVED FIXED
Alias: None
Product: libplasma
Classification: Frameworks and Libraries
Component: components (show other bugs)
Version: 5.48.0
Platform: Neon Linux
: NOR minor
Target Milestone: ---
Assignee: Marco Martin
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2018-07-24 12:39 UTC by Øystein Steffensen-Alværvik
Modified: 2018-09-27 16:17 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.14.0


Attachments
KRunner with Breeze default (5.41 KB, image/png)
2018-07-24 12:39 UTC, Øystein Steffensen-Alværvik
Details
Text becomes visible with PC3 (12.80 KB, image/png)
2018-07-24 22:42 UTC, Nate Graham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Øystein Steffensen-Alværvik 2018-07-24 12:39:04 UTC
Created attachment 114093 [details]
KRunner with Breeze default

See attachment. Using the default look-and-feel and colour theme Breeze, I can barely distinguish the 'Search…' text in KRunner. Seems to be nearly-white text on white.
Comment 1 Nate Graham 2018-07-24 21:30:33 UTC
It's because it uses a PlasmaComponents1 text field, which has this known bug. Kicker has the same issue for the same reason

https://cgit.kde.org/plasma-workspace.git/tree/lookandfeel/contents/runcommand/RunCommand.qml?id=a4a0d5bfd0dabf6be5651244ebe3459b4a257ce2#n65

The PlasmaComponents3 TextField doesn't have this issue, but we haven't ported everything to use that because it doesn't have support for an inline "clear text" button yet. I need to fix that. I'm filing this bug to track it: Bug 396828
Comment 2 David Edmundson 2018-07-24 22:01:52 UTC
What's the issue with the PlasmaComponents 2 text field?

Running tests/components/textfield.qml looks fine.
Comment 3 Nate Graham 2018-07-24 22:04:20 UTC
Its label has the issue described in this bug report. I can reproduce this issue on my Kubuntu 18.04 home machine with 5.12.6, and Øystein can apparently reproduce it with Neon and 5.13.3. Sven Mauch can also reproduce it on Arch with 5.13.3, as described here: https://mauch.me/kdewishlist/
Comment 4 David Edmundson 2018-07-24 22:32:11 UTC
Ack, I misread it as you saying you knew what the bug was.

Anwyay, I did some investigation:

If you attach gammaray the inline preview is fine.
If you find the placeholderTextComponent inner item and set the alpha to 255 it's visible and completely black. 
Turning off compositing brings the text back

So the bug:

There's a habbit in plasmastyles of using opacity to choose a lighter colour.
It's kinda clever as it works on white and black themes.

This isn't just place holder text but also the disabled values of most theme parts.

It works fine if you have an opaque backgrounds. 
Plasma dialogs are practically transparent but with a kwin effect making them grey/white with the background contrast thing. Transparent on transparent does not work effecitve opacity is multiplied into nothing.

PC3 will have the same issue. I don't know how to fix in a way that keeps theme compatibility.
Comment 5 Nate Graham 2018-07-24 22:42:21 UTC
Created attachment 114103 [details]
Text becomes visible with PC3

Switch out the TextField in RunCommand.qml for the PC3 version. The text becomes visible for me; PC3 does not have the same bug (see attached screenshot) And it is a bug, because if the clever logic is designed to choose a good color when the background may be transparent, it's not appropriate for the TextField's label since the background there won't ever be transparent.
Comment 6 David Edmundson 2018-07-24 23:20:08 UTC
Sure it is a bug, but we control drawing the placeholder text and background on both PC2 and PC3. Porting masks the issue instead of fixing it. 
(arguably ok as we're going to port anyway..but it's still kinda cheating)

PC3 *definitely* does a similar thing with opacity. The only difference is that it's an opacity on the item, rather than opacity on the text colour which PC2 has.

I still don't fully get the underlying bug, in theory we are over a solid white background, yet toggling compositing does "fix" it.
Comment 7 Nate Graham 2018-07-25 02:36:54 UTC
I'm not sure why it works, but yeah, the PC3 version doesn't exhibit the bug originally described in this ticket. See my latest attachment to this ticket, and Maybe due to the different theming logic compared to the PC2 version?

So I guess we have a few options here:
1. Find and fix the bug in the PlasmaComponents2 theming logic that causes placeholder text to have the wrong color with light themes
2. Port missing features to the PlasmaComponents3 text field and move PC2 text field users to the new-and-improved PC3 version. I submitted a patch for the first half of this: https://phabricator.kde.org/D14345
3. Create a QQC2-based Kirigami text field that deprecates both of them and has all of their features, and move PC2 and PC3 text field users to it (I'm willing to do this if my patch for #2 is rejected)
4. Something else...?
Comment 8 David Edmundson 2018-08-23 01:59:54 UTC
Chased the bug.

After many hours of going completely mad...it's not our code.

It's a bug in QtQuick ... and only when native rendering is being used.
Somehow when opacity is set on the glyph as well as blending the background it sets the opacity on the final texel, even if there's an opaque item behind it.

PC3 *is* also broken...but detection of which render type to use is also apparently broken(!) which means it's going into the non-native version for the label and we don't see it.
Comment 9 David Edmundson 2018-08-23 11:06:15 UTC
https://bugreports.qt.io/browse/QTBUG-70138
Comment 10 Nate Graham 2018-08-23 13:09:13 UTC
Wow, nice sleuthing!
Comment 11 Øystein Steffensen-Alværvik 2018-08-23 14:04:57 UTC
Thanks for the hard work.
Comment 12 David Edmundson 2018-08-28 09:27:13 UTC
Git commit 2faa71a55a750d54c941aa6dd73ec02cfc9be34b by David Edmundson.
Committed on 28/08/2018 at 09:26.
Pushed by davidedmundson into branch 'master'.

Workaround bug with native rendering and opacity in TextField text

Summary:
Problem is identified in https://bugreports.qt.io/browse/QTBUG-70138
with a potential patch for upstream.

With native rendering the alpha is pointlessly also set in the
glBlendFunc despite also being used in the uniform of the shader.
Resulting in a visual bug when used on a window with alpha (such as
Dialog)

It sucks, but we were starting to see people work round it by copying
more invasive workarounds everywhere else which I want to avoid.

Test Plan: Looked at a text field

Reviewers: #plasma, broulik

Reviewed By: #plasma, broulik

Subscribers: ngraham, kde-frameworks-devel

Tags: #frameworks

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

M  +5    -1    src/declarativeimports/plasmastyle/TextFieldStyle.qml

https://commits.kde.org/plasma-framework/2faa71a55a750d54c941aa6dd73ec02cfc9be34b
Comment 13 Kai Uwe Broulik 2018-09-27 16:17:07 UTC
*** Bug 399143 has been marked as a duplicate of this bug. ***