Bug 157850

I confirm this bug. 
It makes quite impossible to fill forms on web page with black background as text in form is in black too.

See a sample here: http://pacte.blogs.apf.asso.fr/sign.html
note that this page is for impaired users...

Can't confirm. 

I couldn't confirm when i compiled from sources.

But then i installed 4.0.1 packages from debian and then I see it. I don't think it's a distribution thing as such, but something must be different.

Well, I forgot to say I am in Debian Sid, AMD64.

hmm that is 3 times debian - a pattern is emerging :(

I can try in Kubuntu if you need. Do you know if the packages are the same ?

i have no idea, but please try as many distributions as you can

well you can stop when you find a distribution that doesn't show the bug

*** Bug 158981 has been marked as a duplicate of this bug. ***

The bug doesn't happened with kubuntu on AMD64 (I confirmed the bug with Debian on the same computer).
So, it's a Debian bug...

Great, thanks for examining this.
I'll get hold of some debian dev and discuss this

Irronically, quirks mode is OK. Strict & transitional are not.

I have the bug on pages with and without doctype settings

"background-color: transparent" is causing this problem. transparent is default for standards compliant mode whereas other value is probably default for quirks mode. Setting e.g. "background-color: white" for input elements make borders reappear. Can you confirm?

Confirmed with background-color:white for an input field.

In QLineEdit case, Oxygen uses QPalette::Window color to draw QLineEdit frame. If that color is set to QColor(0,0,0,0) (what khtml does in case of background-color: transparent), QLineEdit ends up with non-visible frame.
The problem can be reproduced by writing a simple Qt-only Gui application with a QLineEdit using palette which QPalette::Window & QPalette::Base are set to QColor(0,0,0,0). Example attached below. My setBgColor() is essentially the same to what khtml does to set background color.

There are similar problems with QComboBox, QPushButton (and maybe something else) too. What's more, there's another very annoying problem that QComboBox item scrollbox is completely broken with transparent color (try to scroll it and you should see), but that seems to be generic Qt problem (because other styles suffer from it too).

So this problem does not look like Debian-specific at all. However, I did all these tests on Debian sid/amd64 Qt 4.3.4/kde 3.5.9. Please test on other distros.

I meant kde 4.0.2. Sorry

Created attachment 23870 [details]
Short test case (Qt only)

Compile with:

g++ transtest.cpp -o transtest -I/usr/include/qt4 -lQtCore -lQtGui

I've gone through the debian patches and couldn't find anything to explain why it happens on some distributions and not others.

Thanks Modestas, it sounds like you have cracked it. Yay for the power of opensource :)

I'll try to work on a fix

Tested on Fedora 9 rawhide, Using Oxygen schema. kde 4.0.2. Bug is alive

Any input fields or click-to-check buttons on web pages are invisible until you click on them. It even happens on http://bugs.kde.org .  Hilarious to go hunting for check boxes with you mouse.

*** Bug 156152 has been marked as a duplicate of this bug. ***

*** Bug 159590 has been marked as a duplicate of this bug. ***

transtest.cpp is a horrible example... you asked us to make everything transparent, so we did. Don't do that :-).

I'm looking at improving things when only Window is transparent...

transtest.cpp is a shortened version of *what khtml does* (background-color defaults to transparent as per CSS).

Does khtml *also set button and base transparent*? What exactly are you expecting? You asked us to use transparent for all our drawing (except text) so we did. I've no intention of fixing that and I don't think boemann does either.

I'm investigating making lineedits more clever when only window color is "missing", but if the palette is "empty" there's nothing we can do about it (and if it is, I'd point the finger at khtml, which shouldn't be doing such things).

> Does khtml *also set button and base transparent*?
As far as I can tell, yes, it does. Are you using konqueror 4? If you do, you should see this problem when you look at the "Commit" button below in this page. Offending code is in kdelibs/khtml/rendering/render_replaced.cpp at RenderWidget::updateFromElement()

If you believe khtml is doing something wrong (and you know more about styles than I do), reassign the bug to khtml. I'm not a kde developer, simply this bug is my 'pet' bug so I invested some time into tracking it.

Created attachment 24055 [details]
patch to use Base for 3d effects if Window is invalid

Here's a patch to use Base instead of Window for the 3d-effects drawing (the
shadow in particular) if Window is invalid (i.e. alpha=0). Since I don't seem
to have the problem, can someone please let me know if this works for them?

I can't test with transtest, as for some reason I seem to be getting
Window==Qt::black for that, which results (correctly) in a white shadow color.

I've tested with other styles (Debian sid/amd64, KDE 4.02).
- Phase: same problem
- Motif: same problem
- CDE: same problem
- MS Windows 9x: right and bottom border of fields are invisibles; upper and left border of submit and cancel buttons are invisibles; left and bottom border of select fields are invisibles.
- Cleanlooks: right border of Checkbox and Radio buttons are invisibles, other fields are ok.
- Plastique: everything works.

Is it related to shadow and 3D effects on fields?

Still definitely an issue with Fedora 9 (KDE 4.0.3). I also find that pulldown lists get corrupted display -- is this the same issue?

No, the pulldown lists are bug 157850 ...

Oops, I meant bug 155573

The patch does not fix the problem.

I've tried the URL on the comment #1. The input fields use a clear background. Even bugs.kde.org input fields are ok: them show a border.

This bug seems fixed to me (trunk, r802881).

I'm using trunk too (804262) and I can confirm that the issue is NOT fixed. Maybe this is video driver issue? I'm using nvidia (proprietary) driver on this machine.

I'm using nvidia drivers too.
I've tested on a clean user directory with the default KDE settings.

@Modestas: What version of Qt are you using?

Qt 4.4.0~rc1 for the moment.

Me too. Anyway I'm recompiling trunk with the new 4.4 final. Let see how it will works.

*** This bug has been confirmed by popular vote. ***

Created attachment 24840 [details]
Transparent background fix

In my case Plastique style has the same issue.
As mentioned above - the problem is in the
kdelibs/khtml/rendering/render_replaced.cpp at
RenderWidget::updateFromElement(). if backgroundColor is invalid (alpha is
undefined) and rendering mode not inCompatible (style()->htmlHacks() is true)
then backgroundColor is set to be transparent (0,0,0,0) (QColor(0,0,0,0) IS a
valid color). This explains why in quirks mode rendering is ok (because in this
case backgroundColor is set to backgroundRole). This patch fixes this issue for
me.

If plastique has the same issue, then it is NOT an oxygen bug. Fix khtml to not give us riddiculous palettes; we're just doing what we were told.

hmm, there is a mix of isues here, so lets try to clear things up...

It is perfectly legitimate for KHTML widgets to be as transparent as possible when specifically asked by CSS.
e.g. "background-color: transparent", or "background-color: inherit" when the parent has no color.

But of course this is in no way our default settings.

As you can see in css/html4.css, our widgets have default CSS colours which are mapped to 'sensible' system colours in misc/helper.cpp.

So there is obviously something wrong with the colour setup of vendors for which normal form widget appear transparent.

For instance, a lineedit default background is 'background-color: window' which should map to qApp's QPalette::Base

@Sergey: what your patch says is that you are getting an invalid background-color. And this should not happen with default CSS style..

Could you please investigate what the CSS-to-system colours mappings are on your system?
(See khtml::colorForCSSValue( int css_value ) in misc/helper.cpp
that's the place where wrong things are happening as far as I can tell)

Well, *if* "background-color" was set for element - then everything works ok. In my case "html4.css" didn't contain such definitions (I think it's Debian issue, because in svn version "html4.css" do contain proper "background-color" for every form element).
But I think that there should be some kind of protection against not properly written css files, i.e. KHTML should not make widget to be transparent if no background-color was set for it.

It is not Debian issue (or it's not due to modified html4.css) and Debian does not patch khtml at all:

$ md5sum src/kde/kdesvn/kdelibs/khtml/css/html4.css  /usr/share/kde4/apps/khtml/css/html4.css
61e83bf7e502092f486f428d10616209  src/kde/kdesvn/kdelibs/khtml/css/html4.css
61e83bf7e502092f486f428d10616209  /usr/share/kde4/apps/khtml/css/html4.css

There is 2 packages installed in my system:
kdelibs-data (3.5.8) to support kde3 programms
kdelibs5-data (4.0.72)

first places it's files into /usr/share/apps
second places into /usr/share/kde4/apps

/usr/share/kde4/apps/khtml/css/html4.css (61e83bf7e502092f486f428d10616209) - has all definitions
/usr/share/apps/khtml/css/html4.css (a8249376d53cd223880fa3e2d6dbc810) - don't have "background-color" in form fields definitions.

The main problem is, that KStandardDirs look for html4.css in this order:
/home/user/.kde4/share/apps
/usr/share/apps
/usr/share/kde4/apps

So, the first file which it finds will be html4.css from the kde3.
That's why I'm insist that khtml should properly handle backgroundColor *even* if it is not set in default css file. Setting background to QColor(0,0,0,0) is evil.

Thanks a lot Sergey, you've just pointed to the solution of 2 bugs! (i.e. we need to patch KStandardDirs)

re:#43 
> That's why I'm insist that khtml should properly handle backgroundColor
> *even* if it is not set in default css file. Setting background to
> QColor(0,0,0,0) is evil.

Certainly, but we don't have such choice because we are not the ones who abused the CSS specification by applying random CSS properties to form widgets.
We just go out of our way to provide the best compatibility we can with the web as it is - and the proprietary features of other engines.

For instance, try to paste this in the address bar of a Mozilla browser, then in that of Konqueror:

data:text/html,<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><body style='background:url(http://kde.org/img/kde40.png) no-repeat'><input type=button value=Lorem style=background-color:transparent;font-size:35px>

OTOH, there is indeed room for improvement when using the Oxygen style - we should let the borders be visible when non-focused. Also #155573 is valid - we shouldn't let transparency be inherited by the drop-down widget.
Patches making progress on that fence are very welcome.

Reassigning/retitling in light of Serguey's findings.
Not sure if this is a vendor problem or KDE bug though..

@Germain
I'm not arguing with you against CSS validity, I'm talking about updateFromElement behaviour. *IF* there was "background-color:transparent", then there should be QColor(0,0,0,0), but I don't understand why backgroundColor have to be set to QColor(0,0,0,0) when no "background-color" was set at all!

> we should let the borders be visible when non-focused

We should not ask for invisible widgets unless the CSS genuinely did that. If you (khtml) ask for an invisible widget, and Oxygen obliges you by giving you an invisible widget, that's not a bug. As the joke goes, "don't do that" ("doctor, it hurts when I do this...").

Sergey:  How does Debian setup the KDEDIRS (and XDG_DATA_DIRS for that matter) on your system?  I have the suspicion that /usr is a valid search dir for KStandardDirs but I wasn't aware that KStandardDirs could use paths like /usr/share/kde4.  (KStandardDirs normally appends /share/$type which would lead to paths like /usr/kde4/share/apps, and I don't see any code which would make it /usr/share/kde4/apps).

You want to make sure it has more specific entries before less specific ones.  i.e.

export XDG_DATA_DIRS=/usr/kde4/share:/usr/share

My interpretation of the code is that XDG_DATA_DIRS if set precedes KDEDIRS but you may want to try just settings XDG_DATA_DIRS right and leaving KDEDIRS alone.

I figure Debian patched KDE to search per Debian's guidelines but they need to make sure to search KDE 4 directories before system directories in that case.  (Or in many many less words, I'm not sure that KStandardDirs is really buggy).

For part 2, I don't see what the reason is for making the color transparent when there is no background-color entry set at all, which seems to be the case here?  Is there a way to make the default white (or Background) and only change it if it's actually set in the CSS somewhere?

On Debian there is no /usr/kde4/share folder, there is /usr/share/kde4 (apps,config, e.t.c. all in there).

Debian does not set any environment variables like KDEDIRS or XDG_DATA_DIRS also. (At leas my default-configured user doesn't have any).

For part 2, I've proposed a patch ("transparent background fix"). It does everything you wrote about.

Sergey: Your patch works fine for me and on a strict HTML 4.01 document I constructed seemed to work fine in the cases of:

* No background specified (some solid color was picked up)
* Transparent background chosen (background was transparent)
* Background color specified (the color was used).

This doesn't fix no border being drawn around "invisible" input widgets though, but that's a less pressing issue I think.

I would recommend applying this patch (attachment 24840 [details]) so that Debian users can still get a sane default background color if their system misconfigures the KStandardDirs search path (which I think is the case here, I don't think KStandardDirs is buggy).

SVN commit 813566 by ggarand:

correct default stylesheet is mandatory for proper KHTML operation.
--> versionize, check on start up, abort on mismatch.

Will catch botched setups where kde3 application data dirs are used
instead of kde4's (#157850.)

CCBUG: 157850


 M  +12 -0     cssstyleselector.cpp  
 M  +2 -0      html4.css  


WebSVN link: http://websvn.kde.org/?view=rev&revision=813566

> I don't understand why backgroundColor have to be set to QColor(0,0,0,0) when
> no "background-color" was set at all! 

because that's how CSS work! There is no such thing as an unset CSS property. Properties have initial values. The background-color property's initial value *is* 'transparent'.

> because that's how CSS work! There is no such thing as an unset CSS property. Properties have initial values. The background-color property's initial value *is* 'transparent'. 

Well, I thought that *if* element doesn't have background-color set, then it uses parent's background, *if* parent doesn't have this property set then it uses property of its parent and so on.
I.e. it should end up with main window background (body), but it will be real color, not transparent.
I didn't find in CSS specifications that background-color (or any other color) should have 'transparent' initial value. It said to be UA dependent.
But if you say that it should be transparent - then let it be transparent...
I agree that there should be borders around elements in case of transparency, but what color have to be set for drop-down lists? transparent color make them look very wierd.

Firefox makes form widgets use system widget colors unless otherwise specified, which IMO is The Right Thing To Do. What's odd is that Konqueror, at least my build, seems to do the same? I guess because this box is KDE3-free I don't have the "affects khtml" problem?

And when did invisible widgets become "loss of data or system crashes"? I'm adjusting this bug's severity accordingly. (I'm fine leaving it at "major", but seriously, "grave"?)

*** Bug 162804 has been marked as a duplicate of this bug. ***

*** Bug 162806 has been marked as a duplicate of this bug. ***

Discussed on #kde-devel a couple days ago, the consensus from distro packagers present anyway (Trigger7 and myself mostly, but thiago wasn't convinced yet...) was that
kde4-config --path data
should have the value of 
DATA_INSTALL_DIR (/usr/share/kde4/apps here)
come before 
CMAKE_INSTALL_PREFIX/share/apps (/usr/share/apps)

I took a look at the kstandarddirs.cpp code, and unfortunately to my non-coder eyes, this would be non-trivial to fix cleanly.

I agree that DATA_INSTALL_DIR must be preferred over CMAKE_INSTALL_PREFIX/share/apps. The latter is not used by the installation so there should be no files from the KDE4 installation anyway. All the relevant files should be in DATA_INSTALL_DIR only. AFAICS removing CMAKE_INSTALL_PREFIX/share/apps from the list completely should be correct if all KDE application installs use DATA_INSTALL_DIR.

But I imagine that would break apps that don't set DATA_INSTALL_DIR, especially self compiled KDE applications. So the best fix IMO is to make sure DATA_INSTALL_DIR comes before CMAKE_INSTALL_PREFIX/share/apps.

In case you are not subscribed to kde-core-devel mailing list, A patch was proposed by Sune (thread subject is "kstandarddirs"). Feel free to comments. 

*** Bug 162904 has been marked as a duplicate of this bug. ***

*** Bug 162807 has been marked as a duplicate of this bug. ***

*** Bug 162999 has been marked as a duplicate of this bug. ***

*** Bug 163185 has been marked as a duplicate of this bug. ***

*** Bug 163362 has been marked as a duplicate of this bug. ***

*** Bug 163338 has been marked as a duplicate of this bug. ***

*** Bug 157243 has been marked as a duplicate of this bug. ***

*** Bug 164327 has been marked as a duplicate of this bug. ***

Hi Sune - what happened with your k-c-d patch eventually? I seem to recall reading there were some complications? Is this bug solved now?

Hi Germain. It was committed some time ago in a quite different form after some discussions with especially dfaure.
http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/kernel/kstandarddirs.cpp?r1=819551&r2=819560

I don't know if it is solved in all cases though.

*** Bug 166981 has been marked as a duplicate of this bug. ***

*** Bug 161659 has been marked as a duplicate of this bug. ***

*** Bug 173604 has been marked as a duplicate of this bug. ***

Seems my patch fixed it, since there's no post-4.1 duplicate of this issue (apart from gentoo where the kde3 prefix is allegedly put first in $KDEDIRS, which doesn't make sense for kde4 apps).

*** Bug 175069 has been marked as a duplicate of this bug. ***

*** Bug 176686 has been marked as a duplicate of this bug. ***

*** Bug 192419 has been marked as a duplicate of this bug. ***

To Tommi Tervo:
This is an honest question: how exactly is https://bugs.kde.org/show_bug.cgi?id=192419 a duplicate of this (157850) bug?

*** Bug 210440 has been marked as a duplicate of this bug. ***