Bug 157850 - KStandardDirs picks kde3 application data instead of kde4's when both are installed (affects khtml)
Summary: KStandardDirs picks kde3 application data instead of kde4's when both are ins...
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.0
Platform: unspecified Linux
: NOR major
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
: 156152 157243 158981 159590 161659 162804 162806 162807 162904 162999 163185 163338 163362 164327 166981 173604 175069 176686 192419 210440 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-02-15 05:20 UTC by tkaitchuck
Modified: 2009-10-14 03:45 UTC (History)
26 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Short test case (Qt only) (2.25 KB, text/x-c++src)
2008-03-12 00:17 UTC, Modestas Vainius
Details
patch to use Base for 3d effects if Window is invalid (3.10 KB, patch)
2008-03-26 01:38 UTC, Matthew Woehlke
Details
Transparent background fix (1.75 KB, patch)
2008-05-19 03:53 UTC, Sergey Saukh
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tkaitchuck 2008-02-15 05:20:41 UTC
Version:           unknown (using 4.0.1 (KDE 4.0.1), Debian packages)
Compiler:          cc
OS:                Linux (x86_64) release 2.6.22-3-amd64

Using the default 'Oxygen' schema, Konqueror will make input boxes borderless until the mouse clicks on them. This makes sites like bugs.kde.org virtually unusable as they have the same background color inside the input box as for the page, so one cannot tell the box is even there until you click on it.
Comment 1 Xavier Brochard 2008-03-06 12:39:21 UTC
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...
Comment 2 Maksim Orlovich 2008-03-06 20:21:06 UTC
Can't confirm. 
Comment 3 Camilla Boemann 2008-03-07 00:05:49 UTC
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.
Comment 4 Xavier Brochard 2008-03-07 11:37:30 UTC
Well, I forgot to say I am in Debian Sid, AMD64.
Comment 5 Camilla Boemann 2008-03-07 11:43:16 UTC
hmm that is 3 times debian - a pattern is emerging :(
Comment 6 Xavier Brochard 2008-03-07 11:46:59 UTC
I can try in Kubuntu if you need. Do you know if the packages are the same ?
Comment 7 Camilla Boemann 2008-03-07 11:50:04 UTC
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
Comment 8 Maksim Orlovich 2008-03-08 21:47:48 UTC
*** Bug 158981 has been marked as a duplicate of this bug. ***
Comment 9 Xavier Brochard 2008-03-11 11:31:45 UTC
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...
Comment 10 Camilla Boemann 2008-03-11 11:40:04 UTC
Great, thanks for examining this.
I'll get hold of some debian dev and discuss this
Comment 11 Modestas Vainius 2008-03-11 14:10:24 UTC
Irronically, quirks mode is OK. Strict & transitional are not.
Comment 12 Xavier Brochard 2008-03-11 14:29:07 UTC
I have the bug on pages with and without doctype settings
Comment 13 Modestas Vainius 2008-03-11 15:54:40 UTC
"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?
Comment 14 Xavier Brochard 2008-03-11 18:09:00 UTC
Confirmed with background-color:white for an input field.
Comment 15 Modestas Vainius 2008-03-12 00:14:33 UTC
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.
Comment 16 Modestas Vainius 2008-03-12 00:15:05 UTC
I meant kde 4.0.2. Sorry
Comment 17 Modestas Vainius 2008-03-12 00:17:47 UTC
Created attachment 23870 [details]
Short test case (Qt only)

Compile with:

g++ transtest.cpp -o transtest -I/usr/include/qt4 -lQtCore -lQtGui
Comment 18 Camilla Boemann 2008-03-12 00:25:11 UTC
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
Comment 19 George 2008-03-15 14:36:02 UTC
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.
Comment 20 Maksim Orlovich 2008-03-23 17:33:23 UTC
*** Bug 156152 has been marked as a duplicate of this bug. ***
Comment 21 Maksim Orlovich 2008-03-23 17:33:46 UTC
*** Bug 159590 has been marked as a duplicate of this bug. ***
Comment 22 Matthew Woehlke 2008-03-25 22:29:45 UTC
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...
Comment 23 Modestas Vainius 2008-03-25 22:51:42 UTC
transtest.cpp is a shortened version of *what khtml does* (background-color defaults to transparent as per CSS).
Comment 24 Matthew Woehlke 2008-03-26 01:03:50 UTC
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).
Comment 25 Modestas Vainius 2008-03-26 01:37:14 UTC
> 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.
Comment 26 Matthew Woehlke 2008-03-26 01:38:32 UTC
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.
Comment 27 Xavier Brochard 2008-03-26 09:50:23 UTC
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?
Comment 28 Mary Ellen Foster 2008-04-19 10:41:26 UTC
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?
Comment 29 Mary Ellen Foster 2008-04-19 10:54:25 UTC
No, the pulldown lists are bug 157850 ...
Comment 30 Mary Ellen Foster 2008-04-19 10:55:27 UTC
Oops, I meant bug 155573
Comment 31 Modestas Vainius 2008-04-26 02:41:48 UTC
The patch does not fix the problem.
Comment 32 FiNeX 2008-05-05 15:31:54 UTC
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).
Comment 33 Modestas Vainius 2008-05-05 21:02:01 UTC
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.
Comment 34 FiNeX 2008-05-06 01:25:32 UTC
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?
Comment 35 Modestas Vainius 2008-05-07 11:27:04 UTC
Qt 4.4.0~rc1 for the moment.
Comment 36 FiNeX 2008-05-07 11:58:11 UTC
Me too. Anyway I'm recompiling trunk with the new 4.4 final. Let see how it will works.
Comment 37 Voker57 2008-05-16 17:02:54 UTC
*** This bug has been confirmed by popular vote. ***
Comment 38 Sergey Saukh 2008-05-19 03:53:07 UTC
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.
Comment 39 Matthew Woehlke 2008-05-19 17:48:57 UTC
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.
Comment 40 Germain Garand 2008-05-21 19:03:30 UTC
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)
Comment 41 Sergey Saukh 2008-05-22 05:52:54 UTC
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.
Comment 42 Modestas Vainius 2008-05-22 10:06:26 UTC
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
Comment 43 Sergey Saukh 2008-05-22 11:37:47 UTC
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.
Comment 44 Modestas Vainius 2008-05-22 12:04:40 UTC
Thanks a lot Sergey, you've just pointed to the solution of 2 bugs! (i.e. we need to patch KStandardDirs)
Comment 45 Germain Garand 2008-05-22 14:48:50 UTC
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.
Comment 46 Germain Garand 2008-05-22 15:00:42 UTC
Reassigning/retitling in light of Serguey's findings.
Not sure if this is a vendor problem or KDE bug though..
Comment 47 Sergey Saukh 2008-05-23 04:13:59 UTC
@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!
Comment 48 Matthew Woehlke 2008-05-24 00:13:18 UTC
> 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...").
Comment 49 Michael Pyne 2008-05-27 05:47:58 UTC
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?
Comment 50 Sergey Saukh 2008-05-27 06:02:33 UTC
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.
Comment 51 Michael Pyne 2008-05-28 05:34:51 UTC
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).
Comment 52 Germain Garand 2008-05-28 08:49:28 UTC
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
Comment 53 Germain Garand 2008-05-28 09:09:03 UTC
> 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'.

Comment 54 Sergey Saukh 2008-05-28 12:17:46 UTC
> 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.
Comment 55 Matthew Woehlke 2008-05-28 22:06:30 UTC
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"?)
Comment 56 Germain Garand 2008-05-29 14:12:16 UTC
*** Bug 162804 has been marked as a duplicate of this bug. ***
Comment 57 Germain Garand 2008-05-29 14:13:32 UTC
*** Bug 162806 has been marked as a duplicate of this bug. ***
Comment 58 Rex Dieter 2008-05-29 15:14:22 UTC
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.
Comment 59 Matthias Kretz 2008-05-29 17:54:54 UTC
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.
Comment 60 Fathi Boudra 2008-05-30 07:57:09 UTC
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. 
Comment 61 Germain Garand 2008-05-30 18:06:52 UTC
*** Bug 162904 has been marked as a duplicate of this bug. ***
Comment 62 Germain Garand 2008-05-30 18:14:58 UTC
*** Bug 162807 has been marked as a duplicate of this bug. ***
Comment 63 Maksim Orlovich 2008-06-01 18:56:07 UTC
*** Bug 162999 has been marked as a duplicate of this bug. ***
Comment 64 Tommi Tervo 2008-06-04 08:59:23 UTC
*** Bug 163185 has been marked as a duplicate of this bug. ***
Comment 65 Maksim Orlovich 2008-06-06 18:02:58 UTC
*** Bug 163362 has been marked as a duplicate of this bug. ***
Comment 66 Armin Berres 2008-06-07 15:49:10 UTC
*** Bug 163338 has been marked as a duplicate of this bug. ***
Comment 67 Camilla Boemann 2008-06-09 17:38:30 UTC
*** Bug 157243 has been marked as a duplicate of this bug. ***
Comment 68 Maksim Orlovich 2008-06-19 17:29:01 UTC
*** Bug 164327 has been marked as a duplicate of this bug. ***
Comment 69 Germain Garand 2008-07-09 17:03:41 UTC
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?
Comment 70 Sune Vuorela 2008-07-09 17:09:54 UTC
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.
Comment 71 Maksim Orlovich 2008-07-19 17:43:14 UTC
*** Bug 166981 has been marked as a duplicate of this bug. ***
Comment 72 Maksim Orlovich 2008-08-23 00:34:28 UTC
*** Bug 161659 has been marked as a duplicate of this bug. ***
Comment 73 Dario Andres 2009-01-20 00:08:36 UTC
*** Bug 173604 has been marked as a duplicate of this bug. ***
Comment 74 David Faure 2009-01-20 00:31:46 UTC
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).
Comment 75 Dario Andres 2009-01-24 15:58:55 UTC
*** Bug 175069 has been marked as a duplicate of this bug. ***
Comment 76 Dario Andres 2009-01-24 18:34:24 UTC
*** Bug 176686 has been marked as a duplicate of this bug. ***
Comment 77 Tommi Tervo 2009-05-12 11:53:47 UTC
*** Bug 192419 has been marked as a duplicate of this bug. ***
Comment 78 Steven P. Ulrick 2009-05-12 12:02:09 UTC
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?
Comment 79 Dario Andres 2009-10-14 03:45:44 UTC
*** Bug 210440 has been marked as a duplicate of this bug. ***