See screenshot. PS: I have no idea which frameworks-x component is correct. Please, redirect this bug report. Reproducible: Always - Works correctly with KDE 4.x - Running Neon5 201406101459.iso
Created attachment 87132 [details] Systemsetting - Font Management
Created attachment 89829 [details] kcmshell5 fontinst, messed up preview pane I'll add another screenshot. No characters are visible. Also running Kubuntu plasma5.
*** Bug 341829 has been marked as a duplicate of this bug. ***
I have experienced both situations depicted on the two attachments, on different installations: the one with the jagged edges on a VirtualBox installation and on a laptop using latest NVidia driver, the one with the almost empty window on my desktop using NVidia 340 driver. All installations are Arch Linux, the VirtualBox one is a fresh one.
same here with nvidia340 / plasma5
same here, kubuntu 15.04 nvidia 346.59 kubuntu-backports ppa, kde plasma 5.3
*** This bug has been confirmed by popular vote. ***
*** Bug 346985 has been marked as a duplicate of this bug. ***
Same problem with Fedora 22 and kde5 plasma 5: see this bug on fedora's bugzilla : https://bugzilla.redhat.com/show_bug.cgi?id=1208229 I have same result like attachment "kcmshell5 fontinst, messed up preview pane" For info : --this bug is present with nvidia's drivers --it's present with nouveau drivers, but if I uninstall xorg-x11-drv-nouveau, preview for fonts in system-settings work.
I can confirm on binary nvidia 340something.
I can confirm this bug on Kubuntu 15.04, Plasma 5.3.0, Qt 5.4.1. `glxinfo` says I’m using “Gallium 0.4 on ATI RS690” (xserver-xorg-video-radeon 1:7.5.0-1ubuntu2).
I confirm this bug too on Kubuntu 15.10, Plasma 5.3.1 and Qt 5.4.2 (with this ppa: ppa:kubuntu-ci/stable)
nvidia 352.09 - other font rendering is ok. Craig, the preview seems to use its own rasterizer implementation (and there's xft in the code ;-) I wonder whether that's either necessary and feasible (given that Qt5 exclusively rasterizes internally now) - or one should just QPainter::drawText() down the lines (also reflecting what it will *really* look like in KDE5 applications)
Same problem with Qt 5.5.1 & Plasma from git. System Settings Version 5.4.90, KDE Frameworks 5.15.0.
*** Bug 354010 has been marked as a duplicate of this bug. ***
Also, if you resize the kcm within your systemsettings window which offsets the fontview, you can see the text show through on the sides, behind that overlay with jagged edges.
Still seeing this in F23 KDE spin with all patches applied (NVidia GeForce GTX 650). Also seeing it on a machine with GeForce GT630 and on a ThinkPad T410 with NVidia GT218M [NVS3100M]. All three are using the nouveau driver. I see what's in attachment 89829 [details].
Fun fact. If I select several font (or regular&bold) with control/shift, text looks ok. But when only one font is selected, text is unreadable, just garbage on left/right side.
(In reply to Mykola Krachkovsky from comment #18) > Fun fact. If I select several font (or regular&bold) with control/shift, > text looks ok. But when only one font is selected, text is unreadable, just > garbage on left/right side. Ok, I see the same thing on my Fedora 23, with nvidia drivers. I select several font with control/shift, and I can it see in preview.
fails on kubuntu 15.10 with nvidia and nouveau driver, too. gpu is nvidia geforce gt 330m
ditto with my old GT9600 / nvidia driver 340.93 / plasma 5.4.3 / kf 5.15.0
*** Bug 355951 has been marked as a duplicate of this bug. ***
I am seeing the same as well, including the observation in comment #18. Fedora 22 and 23 both display the problem, 22 is using NVIDIA 340 driver, 23 is using nouveau. Also my F22 and F23 virtual box machines have no problem at all. All systems are current updates against the base and updates repositories, no testing repo's.
*** Bug 355671 has been marked as a duplicate of this bug. ***
I filled the same issue under https://bugs.kde.org/show_bug.cgi?id=355671 . I am on Arch w/ Testing enabled and KDE-Unstable (so latest 5.5 Beta + 15.12 Beta). Latest binary Nvidia drivers (358.16), with a GTX560ti.
Not a very important bug but it need to be fixed. It has be opened 18 month ago.
A reminder.
This is basic functionality for a desktop environment. Why hasn't it been fixed? It makes Plasma look amateurish.
> This is basic functionality for a desktop environment. Why hasn't it been fixed? Here's a couple of reasons for you: * the code is at least 6 years old, with the copyrights going back to early 2000s * the original author is not around anymore * probably nobody actually wants to dive in *thousands* lines of obscure code in their free time * probably nobody understands it > It makes Plasma look amateurish. Dully noted.
> Here's a couple of reasons for you: No, thats no reasons, in this context thats just fine excuses! > * the code is at least 6 years old, with the copyrights going back to early > 2000s > * the original author is not around anymore > * probably nobody actually wants to dive in *thousands* lines of obscure > code in their free time > * probably nobody understands it But in context of providing good and reliable software, these excuses ARE reasons to rewrite this piece of outdated crap. Thomas Lübking wrote: >Craig, the preview seems to use its own rasterizer implementation (and there's xft in the code ;-) >I wonder whether that's either necessary and feasible (given that Qt5 exclusively rasterizes internally now) - or one should just QPainter::drawText() down the lines (also reflecting what it will *really* look like in KDE5 applications) This makes me think, that it wouldn be *thousands* LOC that nobody understands.... This comment is IMHO the result of a short look on the code..... Dont get me wrong, I really like KDE and enjoy it in my everyeday work and i am thankful to all of the developers spending their free time. But this issue is just another example, why open source software often sucks. Instead of taking bugs serious and fix them, at the latest to the next major release, the implementation of new features seems to be first in schedule. > > It makes Plasma look amateurish. No, It MAKES Plasma/KDE amateurish! Regards
> No, thats no reasons, in this context thats just fine excuses! Right, you do know that KDE is /all/ open source right? So what's your excuse to NOT join the development? > This makes me think, that it wouldn be *thousands* LOC that nobody understands.... This comment is IMHO the result of a short look on the code..... Please, by all means, go ahead and decide for yourself how many LOC that whole thing actually has: https://quickgit.kde.org/?p=plasma-desktop.git&a=tree&h=493b93b5abdb79af65fae716a62fae7be932b438&hb=6e0d0c49a3cf5881757b57f55c60033efd6cb3d1&f=kcms%2Fkfontinst --- That said, please let's keep the comments on topic. Posting angry/insulting comments will really really really not help you get this fixed faster (if at all).
a) @Martin K., wtf happened to Craig, is he fine? (pm me in doubt) b) in any case this is apparently unmaintained bitrot - and that's neither an "excuse" nor a "reason" for the bug - it's an "explanation" c) it /is/ a hell lot of rather opaque code, but as mentioned most of it seems to go into a custom font renderer. My personal assumption would be that this could just be omitted, but I have no knowledge on why it's therer itfp. (I first and only glimpsed at the code on that one occasion) With the author/maintainer absent, one may simply resort to that and see what other bugs cook up (then simply revert the commit on trouble) d) nothing of all that excuses the attitude of some people here around. It annoys you? Hell, just fix it. You can't? Well, find somebody. In doubt set a bounty. You can neither? The you got to live with it. Reporting bugs is important and a valuable contribution, but the first answer to "why is it not yet fixed? why is it not yet fixed?" is always "because you didn't fix it?" And you better start begging that Craig is ok and just moved on. For any solution: ---------------------- Iff Craig won't return, we'll need somebody to pick the component as maintainer (and fix it). That is important because the "fix" may break other things and somebody has to care about it. If you want to give it a try (assuming the scary fontconfig code gone, it should actually not be very hard - it's a choice the maintainer has to take; i'm not too convinced that the custom rendering can be rescued with the changesto Qt5), feel free to ask for advise and help anytime (ideally on the kde-devel mailing list) -------------------------------------------- > > > It makes Plasma look amateurish. > No, It MAKES Plasma/KDE amateurish! And how do we call people who use amateurish software? :-P
No clue about Craig, but he sure is missed. But I'm thinking we could just add brand new font rendering widget to the kcm that replaces the old one and leave everything else in place (including the bitrotted code). That way we could get a working Qt5 renderer and keep the old one around for things that may break or something. The whole thing desperately needs a maintainer though.
(In reply to Martin Klapetek from comment #33) > But I'm thinking we could just add brand new font rendering > widget to the kcm that replaces the old one and leave everything > else in place (including the bitrotted code). > > That way we could get a working Qt5 renderer and keep the old > one around for things that may break or something. > > The whole thing desperately needs a maintainer though. While thinking about correcting this bug, one has to remember comment #18: if multiple fonts are selected, they appear fine. So this may be easier to solve than the convolved code lets one think, and some experienced KDE developer could probably decipher this.
First of all, I apologize for my harsh sounding post yesterday. My goal was not to offend someone. But my criticism about favour implementation new features vs. fixing (old) bugs still remains. After a few hours of reading i have to confess that kfontinst IS a hell of opaque, uncommented code, but the Problem for this issue is IMHO the /lib/FcEngine class. Due to the fact that the whole component is closely interweaved with the system and that i have no clue about KDE development, it is (by now) not a good idea to offer my work as a maintainer for this module. But I am on turn to setup a dev environment, read docs and check whether it is possible for me to maintain this module in future. If so, i will come forward at the devel mailinglist.
(In reply to Nikos Platis from comment #34) > While thinking about correcting this bug, one has to remember comment #18: > if multiple fonts are selected, they appear fine. So this may be easier to > solve than the convolved code lets one think, and some experienced KDE > developer could probably decipher this. Sorry, for my System this workaround still wont work. The only difference is, that the backround of the preview(s) change to white.
> If so, i will come forward at the devel mailinglist. Please do, it would be most welcome (plasma-devel at kde.org) I think it would be nice to modernize the code quite a bit. With that in mind, I think that the font preview could just be scrapped and done from scratch. I imagine it's not that hard given you already have at least some understanding of the code; you just need the font that is selected on the left, pass it to the preview widget and have the widget paint stuff using eg. QPainter.
(In reply to Martin Klapetek from comment #33) > But I'm thinking we could just add brand new font rendering > widget to the kcm that replaces the old one and leave everything > else in place (including the bitrotted code). Hummm... that kicked something in my brains. The view isn't only required for the kcm, but also for kfontview. In addition it must be able to handle *specific* fonts from files, which are not (yet) installed in the system - so I guess the cause for the custom code was either the absence of QFontDataBase before Qt 4.2 or it's dependency on fontconfig? @Thomas S.: you'll have to make use of the class when/if porting the view. Reg. the multiselection: the view replaces the preview by a list of the selected font names in a QLabel here then (what oc. works like any regular font rendering), but the broken rendering does look like an issue with the color/alpha channels - what you indicate the "wrong" visual id or picture format is selected (yet even if, the code is too complex if the task can be done by QFontDatabase + QPainter)
I have the same bad font rendering issue with UXA rendering mode of the Intel driver. SNA works correctly.
Sure it's this bug? Can you provide screenshots of UXA and SNA rendered fonts?
SNA: https://www.dropbox.com/s/tzrt2qrx547jagu/SNA.png?dl=0 UXA: https://www.dropbox.com/s/wi199ccg7ql7pz4/UXA.png?dl=0
Yes, is. Stunning. The xft image is RGB32 here, may depend on whether it's set to translucent (though there ARGB32 instead of pre-multiplied is used) We need this patch tested on all possible GPUs (notably intel/sna!) diff --git a/kcms/kfontinst/lib/FcEngine.cpp b/kcms/kfontinst/lib/FcEngine.cpp index 19b7206..6c731dc 100644 --- a/kcms/kfontinst/lib/FcEngine.cpp +++ b/kcms/kfontinst/lib/FcEngine.cpp @@ -537,7 +537,7 @@ QImage CFcEngine::Xft::toImage(int w, int h) const if (!xImage) { return QImage(); } - return QImage(xImage->data, xImage->width, xImage->height, xImage->stride, QImage::Format_ARGB32_Premultiplied, &cleanupXImage, xImage); + return QImage(xImage->data, xImage->width, xImage->height, xImage->stride, QImage::Format_RGB32, &cleanupXImage, xImage); } inline int point2Pixel(int point)
Resp. this one (the ARGB32 translucency handling is uncritical, it's applied to the preconverted image. This should be the single point of failure) diff --git a/kcms/kfontinst/lib/FcEngine.cpp b/kcms/kfontinst/lib/FcEngine.cpp index 19b7206..012a9d5 100644 --- a/kcms/kfontinst/lib/FcEngine.cpp +++ b/kcms/kfontinst/lib/FcEngine.cpp @@ -537,7 +537,14 @@ QImage CFcEngine::Xft::toImage(int w, int h) const if (!xImage) { return QImage(); } - return QImage(xImage->data, xImage->width, xImage->height, xImage->stride, QImage::Format_ARGB32_Premultiplied, &cleanupXImage, xImage); + QImage::Format format = QImage::Format_RGB32; + switch (DefaultDepth(QX11Info::display(), 0)) { + case 32: format = QImage::Format_ARGB32_Premultiplied; break; + case 16: format = QImage::Format_RGB16; break; + case 8: format = QImage::Format_Grayscale8; break; + default: break; + } + return QImage(xImage->data, xImage->width, xImage->height, xImage->stride, format, &cleanupXImage, xImage); } inline int point2Pixel(int point)
(In reply to Thomas Lübking from comment #43) > Resp. this one (the ARGB32 translucency handling is uncritical, it's applied > to the preconverted image. This should be the single point of failure) > > diff --git a/kcms/kfontinst/lib/FcEngine.cpp > b/kcms/kfontinst/lib/FcEngine.cpp > index 19b7206..012a9d5 100644 > --- a/kcms/kfontinst/lib/FcEngine.cpp > +++ b/kcms/kfontinst/lib/FcEngine.cpp > @@ -537,7 +537,14 @@ QImage CFcEngine::Xft::toImage(int w, int h) const > if (!xImage) { > return QImage(); > } > - return QImage(xImage->data, xImage->width, xImage->height, > xImage->stride, QImage::Format_ARGB32_Premultiplied, &cleanupXImage, xImage); > + QImage::Format format = QImage::Format_RGB32; > + switch (DefaultDepth(QX11Info::display(), 0)) { > + case 32: format = QImage::Format_ARGB32_Premultiplied; break; > + case 16: format = QImage::Format_RGB16; break; > + case 8: format = QImage::Format_Grayscale8; break; > + default: break; > + } > + return QImage(xImage->data, xImage->width, xImage->height, > xImage->stride, format, &cleanupXImage, xImage); > } > > inline int point2Pixel(int point) I use Fedora 23 and I have same problem (see comment 9) I rebuild the fedora's rpm with your patch (plasma-desktop-5.5.3-2.fc23.x86_64.rpm), and now all work fine, I can see the font in system settings. Thank for that.
(In reply to Thomas Lübking from comment #43) > Resp. this one (the ARGB32 translucency handling is uncritical, it's applied > to the preconverted image. This should be the single point of failure) > > diff --git a/kcms/kfontinst/lib/FcEngine.cpp > b/kcms/kfontinst/lib/FcEngine.cpp > index 19b7206..012a9d5 100644 > --- a/kcms/kfontinst/lib/FcEngine.cpp > +++ b/kcms/kfontinst/lib/FcEngine.cpp > @@ -537,7 +537,14 @@ QImage CFcEngine::Xft::toImage(int w, int h) const > if (!xImage) { > return QImage(); > } > - return QImage(xImage->data, xImage->width, xImage->height, > xImage->stride, QImage::Format_ARGB32_Premultiplied, &cleanupXImage, xImage); > + QImage::Format format = QImage::Format_RGB32; > + switch (DefaultDepth(QX11Info::display(), 0)) { > + case 32: format = QImage::Format_ARGB32_Premultiplied; break; > + case 16: format = QImage::Format_RGB16; break; > + case 8: format = QImage::Format_Grayscale8; break; > + default: break; > + } > + return QImage(xImage->data, xImage->width, xImage->height, > xImage->stride, format, &cleanupXImage, xImage); > } > > inline int point2Pixel(int point) This patch solved the bug on openSUSE Leap 42.1 and nouveau (a NVD9 card)
(In reply to Thomas Lübking from comment #42) > We need this patch tested on all possible GPUs (notably intel/sna!) Great ! You have killed this bug :) My GPU : NVIDIA Corporation G94 [GeForce 9600 GT] (rev a1) Driver : nvidia-340xx Many thanks
(In reply to Thomas Lübking from comment #42) > We need this patch tested on all possible GPUs (notably intel/sna!) I forgot that. I test on laptop Toshiba Sattelite L775, nvidia card GeForce GT 525M and nvidia drivers 358.16
NVidia GeForce GT 240M, proprietary driver 340.96. It looks OK both installed font list and viewing uninstaled font from file.
Thanks everyone, but the test I mostly wait for is that on intel/sna (I assume the format was hardcoded because it worked on that driver and I don't want to break it - it's too common)
(In reply to Thomas Lübking from comment #49) > Thanks everyone, but the test I mostly wait for is that on intel/sna (I > assume the format was hardcoded because it worked on that driver and I don't > want to break it - it's too common) SNA compiled from 2.99.917-519-g8229390 SNA initialized with Haswell (gen7.5, gt1) backend I've just checked it on my HP chromebook running archlinux with the driver intel/sna. I didn't notice any regression. It's OK.
Thanks a lot. Risking to be a complete PITA, mind testing this patch and notably watching on whether you're on 32bit depth and whether a format is found (and it's the correct one ;-) diff --git a/kcms/kfontinst/lib/FcEngine.cpp b/kcms/kfontinst/lib/FcEngine.cpp index 19b7206..6026753 100644 --- a/kcms/kfontinst/lib/FcEngine.cpp +++ b/kcms/kfontinst/lib/FcEngine.cpp @@ -219,6 +219,7 @@ class CFcEngine::Xft XftColor itsTxtColor, itsBgndColor; Pix itsPix; + QImage::Format imageFormat; }; CFcEngine::Xft::Xft() @@ -267,6 +268,47 @@ bool CFcEngine::Xft::init(const QColor &txt, const QColor &bnd, int w, int h) XftColorAllocValue(QX11Info::display(), visual, colorMap, &xrenderCol, &itsTxtColor); } + XVisualInfo defaultVinfo; + defaultVinfo.depth = DefaultDepth(QX11Info::display(), 0); + // normal/failsafe + imageFormat = QImage::Format_RGB32; // 24bit + switch (defaultVinfo.depth) { + case 32: imageFormat = QImage::Format_ARGB32_Premultiplied; break; + case 30: imageFormat = QImage::Format_RGB30; break; + case 16: imageFormat = QImage::Format_RGB16; break; + case 8: imageFormat = QImage::Format_Grayscale8; break; + default: break; + } + qDebug() << "Depth" << defaultVinfo.depth; + if (defaultVinfo.depth == 30 || defaultVinfo.depth == 32) { + // detect correct format + int num_vinfo = 0; + defaultVinfo.visual = DefaultVisual(QX11Info::display(), 0); + defaultVinfo.screen = 0; + defaultVinfo.visualid = XVisualIDFromVisual(defaultVinfo.visual); + XVisualInfo *vinfo = XGetVisualInfo(QX11Info::display(), VisualIDMask|VisualScreenMask|VisualDepthMask, &defaultVinfo, &num_vinfo); + for (int i = 0; i < num_vinfo; ++i) { + if (vinfo[i].visual == defaultVinfo.visual) { + if (defaultVinfo.depth == 30) { + if (vinfo[i].red_mask == 0x3ff) + imageFormat = QImage::Format_BGR30; + else if (vinfo[i].blue_mask == 0x3ff) + imageFormat = QImage::Format_RGB30; + } else if (defaultVinfo.depth == 32) { + if (vinfo[i].blue_mask == 0xff) + imageFormat = QImage::Format_ARGB32_Premultiplied; + else if (vinfo[i].red_mask == 0x3ff) + imageFormat = QImage::Format_A2BGR30_Premultiplied; + else if (vinfo[i].blue_mask == 0x3ff) + imageFormat = QImage::Format_A2RGB30_Premultiplied; + } + qDebug() << "Found one" << imageFormat; + break; + } + } + XFree(vinfo); + } + if(itsPix.allocate(w, h) && itsDraw) XftDrawChange(itsDraw, itsPix.x11); @@ -537,7 +579,7 @@ QImage CFcEngine::Xft::toImage(int w, int h) const if (!xImage) { return QImage(); } - return QImage(xImage->data, xImage->width, xImage->height, xImage->stride, QImage::Format_ARGB32_Premultiplied, &cleanupXImage, xImage); + return QImage(xImage->data, xImage->width, xImage->height, xImage->stride, imageFormat, &cleanupXImage, xImage); } inline int point2Pixel(int point)
(In reply to Thomas Lübking from comment #51) > Thanks a lot. Risking to be a complete PITA, mind testing this patch and > notably watching on whether you're on 32bit depth and whether a format is > found (and it's the correct one ;-) Testing again the new patch. It's still ok but i am in 24bits. How can i do to test 30/32bits depth ?
Created attachment 96566 [details] FcEngine patch I have attached your patch because cut&past kills correct formatting
(In reply to hamelg from comment #52) > Testing again the new patch. It's still ok but i am in 24bits. How can i do > to test 30/32bits depth ? You can't - that's a server thing. Seems the image just has a degenerated alpha channel on SNA but not on UXA (and most other drivers) - what could indicate the ARGB_premultiplied is generally wrong. *shrug* - we shall just jump into the pool and wait until somebody with an exotic color table reports a bug.
https://git.reviewboard.kde.org/r/126713/
I'm an artist and depend on KDE. I have a novice understanding of computer science (took CS50). I have no clue how to apply this patch, but just purchased a bulk of fonts and need to sort them. Would anyone mind providing a link that will help me understand what to do to get this patch applied? If not, how long will it take for this patch to get rolled into an official release? Kernel: 4.3.3-2-ARCH Shell: /bin/bash DE: Plasma 5.5.3-2
You need to get the sources of plasma-desktop, apply the patch (patch -p1 < path/to/patch.diff) and rebuild at least kcms/kfontinst. If you've no experience with compilation, you can ask your distro to pre-pick the patch (ask implies the answer may be "no") There's no schedule on when this patch hits downstream, sorry. It's not even applied upstream yet.
(In reply to Thomas Lübking from comment #57) > You need to get the sources of plasma-desktop, apply the patch (patch -p1 < > path/to/patch.diff) and rebuild at least kcms/kfontinst. > > If you've no experience with compilation, you can ask your distro to > pre-pick the patch (ask implies the answer may be "no") > There's no schedule on when this patch hits downstream, sorry. It's not even > applied upstream yet. Thanks - I'm not sure that I understand what you've said here, but it's a starting point for some google-foo.
In the mean time you can simply install gnome-font-viewer
(In reply to jeremy9856 from comment #59) > In the mean time you can simply install gnome-font-viewer Thanks - I just installed it. This will at least allow me to view the fonts correctly. I can use this in conjunction with Font Management in the Plasma 5 settings to sort them.
(In reply to Garland_Key from comment #56) If not, how long will it take for this patch to get rolled into an > official release? > > Kernel: 4.3.3-2-ARCH > Shell: /bin/bash > DE: Plasma 5.5.3-2 That depend to the maintainer for plasma-desktop in your distro (ARCH). For example, in my distro (Fedora) the maintainer has already apply this patch in plasma-desktop-5.5.3-3.fc23.rpm. I install this update and that work fine.
(In reply to Thomas Lübking from comment #55) > https://git.reviewboard.kde.org/r/126713/ This Patch works, Thanks. My Setup: Gentoo Linux; Kernel 4.4.0 (vanilla); Qt 5.5.1; KDE Framework 5.18; KDE Plasma 5.5.2
Works great on Fedora 23, thanks very much!
(In reply to chepioq from comment #61) > (In reply to Garland_Key from comment #56) > If not, how long will it take for this patch to get rolled into an > > official release? > > > > Kernel: 4.3.3-2-ARCH > > Shell: /bin/bash > > DE: Plasma 5.5.3-2 > > That depend to the maintainer for plasma-desktop in your distro (ARCH). > > For example, in my distro (Fedora) the maintainer has already apply this > patch in plasma-desktop-5.5.3-3.fc23.rpm. > > I install this update and that work fine. I've filed a bug report at arch and posted a link to this report/patch.
Git commit 9977edac12d6bec56f8d9cf7f97529177ca842eb by Thomas Lübking. Committed on 15/01/2016 at 21:02. Pushed by luebking into branch 'Plasma/5.5'. fix font preview colors the image format was hardcoded to ARGB32_Premultiplied, but that's not generally correct, notably not on 24bit servers FIXED-IN: 5.5.4 REVIEW: 126713 M +41 -1 kcms/kfontinst/lib/FcEngine.cpp http://commits.kde.org/plasma-desktop/9977edac12d6bec56f8d9cf7f97529177ca842eb
*** Bug 358728 has been marked as a duplicate of this bug. ***
*** Bug 357001 has been marked as a duplicate of this bug. ***
*** Bug 356444 has been marked as a duplicate of this bug. ***