Launchpad will sync comments and link back to all bug watches, even those not linked to a bug task

[Micah Gersten]

What happens:
If a bug has a bug watch against an upstream bug, even if that upstream bug has nothing to do with the actual bug, Launchpad will still sync comments for that bug watch and add a back link, where possible.

For example, bug 454166 was fixed by a change to a package and the changelog was posted to the bug as a comment by the LP Janitor. This comment contained the URL of an upstream bug, so a bug watch was created for that upstream bug.

Checkwatches then imported the comments from that upstream bug, even though the upstream bug had nothing to with the Launchpad bug. (see http://paste.ubuntu.com/333331/ for the resulting bugspam).

Also, complaints have been made upstream about the automatic back-links that Launchpad makes. If an bug is mentioned in a Launchpad bug comment and thus has a watch generated for it that watch will then be linked back to the upstream bug, even if it's not even tangentially related to the Launchpad bug in question.

What should happen:
Checkwatches should only sync comments and backlink when a bug watch is actually linked to a BugTask. That will eliminate this problem (unless someone adds a nonsensical BugWatch to a BugTask, but we can't prevent users from doing odd things all the time).

[Bugzilla-lostreality (bugzilla-lostreality)]

Created an attachment (id=248671)
What a menu looks like under 3.0a1

If you compare this to 2.0, you can tell that the right pixel is cut off of each line of text. It is most obvious on the lowercase 's' on the bottom two options shown in that picture. The left pixel is also cut off of each line, but it is harder to tell. All of the text is clearly "dimmer" looking and not properly aliased for cleartype display, causing it to not look as sharp as it should and does under 2.0 and other browsers. Another small change noticeable is the space between the T and F on the second and third lines is 1 pixel less in 3.0a1 for some reason.

[Bugzilla-lostreality (bugzilla-lostreality)]

Created an attachment (id=248672)
What a menu looks like under 2.0

[Googulator (netrolller-3d)]

It seems that Cairo is unable to correctly detect the subpixel ordering of the screen, and does a BGR-ordered ClearType on the text. Or maybe a result of both Cairo and Windows attempting to antialias the text.

[Googulator (netrolller-3d)]

Confirming bug in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1.

Further investigation shown that Cairo selects the wrong contrast level when rendering the text. Setting contrast to 1.0 using ClearType fixes the issue (although text will likely to look weird in other places if that is set). Probably Cairo incorrectly reads the contrast values and takes them as if they were squared (e.g. a level of 1.4 is treated as 1.4^2, that's around 2.0, while 1.0 is processed as 1,0^2=1.0). Another thing I noticed is that if you hover over the menu items, the bug disappears, but opening a submenu causes it to re-appear. Testcase coming soon.

[Googulator (netrolller-3d)]

Created an attachment (id=248910)
Testcase

Testcase. Hover over the menu in it to trigger the bug.

[Googulator (netrolller-3d)]

It looks like the culprit is in cairo-win32-font.c, judging from these comments (line 1186):

"* Otherwise, we need to draw using software fallbacks. We create a mask
 * surface by drawing the the glyphs onto a DIB, black-on-white then
 * inverting. GDI outputs gamma-corrected images so inverted black-on-white
 * is very different from white-on-black. We favor the more common
 * case where the final output is dark-on-light."

After that (at line 1212):

"* For ClearType, we need a 4-channel mask. If we are compositing on
 * a surface with alpha, we need to compute the alpha channel of
 * the mask (we just copy the green channel). But for a destination
 * surface without alpha the alpha channel of the mask is ignored"
(Let's not forget that our surface is semi-transparent, so it does have an alpha!)

And a few lines later (line 1225):

"* XXX: Hacky, should expose this in cairo_image_surface"

Probably this is a bug in Cairo itself, but it seems to need quite a major rewrite.

[Vladimir Vukicevic (vvuk)]

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

[Dao (dao)]

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

[Stream (stream)]

Created an attachment (id=308313)
screenshot from lineage2.com

On hover the bug is still visible. See the attachment. Why this bug is not blocker, when clear type technology is used mostly in LCD monitors, and its full of them now.

[Tgstrick (tgstrick)]

Created an attachment (id=314121)
ClearType/Opacity bug in 3 Beta 5 - Inline HTML (No layers/DHTML)

Seems like this bug has gotten worse in 3 Beta 5... I'm using opacity to fade out adjacent month dates in our in-house web calendars, and in Beta 5 the '1' digits are suffering badly. This is all relatively positioned CSS, no floats, no z-indexing or layers. Problem goes away with ClearType turned off.

[6XGate (sixxgate)]

This bug also manifests itself in the chrome as well if the element or it's parent uses opacity or has rounded borders (-moz-border-radius) The Glasser extension screenshots show this problem alot:

http://www.neowin.net/forum/index.php?showtopic=632112

[Sauron-ubufox (sauron-ubufox)]

I absolutely consider the Glasser extension an essential now, but this bug is really bugging me quite a lot. I tried turning off ClearType, but the font looks absolutely hideous on a LCD monitor.

[Kliu (kliu)]

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

[Aurelius-bw (aurelius-bw)]

The Glasser Extension does not work properly because of this ...

[Redsign (redsign)]

That's nothing new but there also many websites that just look crappy because of this. It's really sad that this doesn't get fixed for 3.0.

[Kliu (kliu)]

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

[Bugzilla-dailybuzz (bugzilla-dailybuzz)]

Created an attachment (id=321706)
A sample HTML file showing css opacity usage with various color text and background

[Bugzilla-dailybuzz (bugzilla-dailybuzz)]

Created an attachment (id=321707)
opacity_test_p.html with cleartype enabled

Rendered in Firefox 3 RC1 on Windows Vista.

[Bugzilla-dailybuzz (bugzilla-dailybuzz)]

Created an attachment (id=321708)
opacity_test_p.html with cleartype disabled

Rendered in Firefox 3 RC1 on Windows Vista.

[Kliu (kliu)]

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

[Kliu (kliu)]

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

[Kliu (kliu)]

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

[Kliu (kliu)]

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

[Kliu (kliu)]

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

[Dsicore (dsicore)]

Don't think this would block the 1.9.1 release. Minusing.

[Regis-caspar+bz (regis-caspar+bz)]

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

[Kliu (kliu)]

What I'm curious about is why painting ClearType text onto a surface with alpha forces cairo to take the software fallback branch in the first place. Gecko 1.8 never had problems with drawing ClearType onto something with opacity, so what is it about cairo surfaces that prevents direct drawing?

[Me-at-work (me-at-work)]

Does this bug depend on bug 407531, or vice versa?

[Kliu (kliu)]

(In reply to comment #28)
> Does this bug depend on bug 407531, or vice versa?
>

Neither.

[Bugzilla-moeffju (bugzilla-moeffju)]

The problem seems to be in ClearType since 1.0.4, see http://lists.cairographics.org/archives/cairo/2006-October/008081.html

There is also a 'very large hammer' fix in that thread (force surface format to CAIRO_FORMAT_RGB24).

[Mcs-pearlcrescent (mcs-pearlcrescent)]

Created an attachment (id=339121)
XUL testcase using <menupopup>

Someone else I am working with encountered this bug when creating a theme that uses rounded corners and transparency with menus. In case it helps someone debug the problem, I am attaching a XUL-based testcase.

[Mcs-pearlcrescent (mcs-pearlcrescent)]

Created an attachment (id=339123)
screenshot of XUL testcase result (ClearType on, scaled to 200%)

[Mcs-pearlcrescent (mcs-pearlcrescent)]

Created an attachment (id=339124)
screenshot of XUL testcase result (ClearType off, scaled to 200%)

[M-h-perris (m-h-perris)]

Created an attachment (id=347965)
BBC Homepage Snippet

This is now visible on the BBC Homepage. The link on the right of the attached image has been hovered once, and the color has changed. Once the cursor is moved out of the box, the color reverts to it's original incorrectly cleartyped style.

[Googulator (netrolller-3d)]

It appears that Microsoft is at least partially responsible for this bug - Firefox 3.0b1 renders the testcases significantly better on Windows 7 beta 1 than on Windows Vista SP1. Attachment 248910 does not show any bug now, while attachment 321706 only gets the white-on-white one wrong (and even that one is much better than on Vista). Attachment 339121 now only shows the rightmost-pixels-cut-off bug, no contrast problem is visible.

[Googulator (netrolller-3d)]

Seems that the problem is the fact that we "just copy the green channel" to get the alpha channel. The following testcases clearly point to this:
data:text/html,<div style="background: white;"><div style="color: white; opacity: 0.999; font-size: 36px;">FAIL</div></div>
This one faintly displays the word "FAIL", even though it is white-on-white, and as such, should be invisible. What is visible appears to be a cyan line on the left (cyan=blue+green), and a yellow one on the right of the text (yellow=red+green); both colors contain the color green as a component.
These also show incorrect rendering:
data:text/html,<div style="background: red;"><div style="color: red; opacity: 0.999; font-size: 36px;">FAIL</div></div> (part of the red color is missing on the left side of the letters, black is visible)
data:text/html,<div style="background: blue;"><div style="color: blue; opacity: 0.999; font-size: 36px;">FAIL</div></div> (part of the blue is missing on the right of the letters)
data:text/html,<div style="background: cyan;"><div style="color: cyan; opacity: 0.999; font-size: 36px;">FAIL</div></div> (part of the blue color is missing, green shows through)
data:text/html,<div style="background: magenta;"><div style="color: magenta; opacity: 0.999; font-size: 36px;">FAIL</div></div> (red is missing on the left, while the right lacks blue)
data:text/html,<div style="background: yellow;"><div style="color: yellow; opacity: 0.999; font-size: 36px;">FAIL</div></div> (red is mising, green shows through)

These pass however:
data:text/html,<div style="background: black;"><div style="color: black; opacity: 0.999; font-size: 36px;">FAIL</div></div>
data:text/html,<div style="background: green;"><div style="color: green; opacity: 0.999; font-size: 36px;">FAIL</div></div>
data:text/html,<div style="background: lime;"><div style="color: lime; opacity: 0.999; font-size: 36px;">FAIL</div></div>

What I have noticed is that we only pass if R=0 and B=0, i.e. color=#00xx00, where xx is any hex number. This is because the only channel for which the alpha mask is correct is green, as we use the green channel for our alpha mask.
However, if any other channel is present, the alpha mask will show an off-by-one-subpixel problem, and the rendering of the non-green channels will be corrupted.

So, basically copying the green channel to the alpha channel is wrong, the actual alpha channel should take all color channels into account. This bug, probably coupled with a bug in ClearType in pre-7 Windowses, is the most likely cause of the misrendering.

I'll probably back with a proof-of-concept patch soon.

[Googulator (netrolller-3d)]

Created an attachment (id=358765)
WIP 0.000001: Move away from using the green channel as the alpha

Extremely-early preview of what I am working on right now.
With this patch, testcases involving extreme colors (white-on-white, black-on-black, #ff0000 on #ff0000, #00ffff on #00ffff) pass, but other tests still show errors, and real-life rendering is also still wrong. This is because the dummy maximum algorithm used in this patch is just a placeholder, and is definitely not correct. However, the basic structure of the _compute_argb32_mask_alpha function is in place, only an alpha-channel generation algorithm is needed. I think I need to convert the RGB colors to HSL and use the lightness value as the alpha, although I am not sure.

If you have an idea what the correct algorithm would be, please post it here!

[Zurtex (zurtex)]

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

[Tchraven (tchraven)]

I just ran into this as well, any progress being made on this?

[SelenIT (selenit)]

I found another opacity and anti-aliasing related artifact. When I use 'Arial Black' font (about 18px size) together with opacity less than 1.0, the text appears a bit thinner (as if it had smaller font-weight). With larger font size the visual difference becomes less. Without anti-aliasing the text rendering doesn't change because of the opacity, but with 'standard' anti-aliasing the similar artifact still appears (so it may be not only ClearType-related problem). I didn't investigate if this happens to other fonts yet.

[SelenIT (selenit)]

Created an attachment (id=392986)
Demo of anti-aliased 'Arial Black' font with opacity issue

[Gingerbreadguy (gingerbreadguy)]

Created an attachment (id=396127)
Buried story on Digg showing text with green halo

Burying stories on Digg.com displays the text with a sort of green halo around it.

Someone else has reported that this problem also occurs when deleting images on Flickr, and that it does not occur on Vista 32-bit (I am using Vista x64). The Mozillazine thread in question is http://forums.mozillazine.org/viewtopic.php?f=38&t=1414815

[Zurtex (zurtex)]

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

[Goran-baotic (goran-baotic)]

I'm not active in bugzilla community, so pardon me for dropping in.
I'd just like to point out the circumstances under which the bug occurs:

- *** 64-bit *** Windows Vista / 7
- ClearType set to ON

I didn't succeed in replicating the bug on 32-bit versions of Vista/7, even
with ClearType set to on, so I think it's a 64-bit problem. I haven't tested teh bug on XP/64-bit.

Green artifacts appear on text elements when opacity is set to less than 1
(.999 or less). Clearly visible on jQuery or similar JS fade in/out effects
that utilize fast changes to element opacity.

I'm also having issues with PNG rendering in Firefox 3.5.* when color
management is turned on. Setting "gfx.color_management.mode" to 0 fixes the
issue. This is also a bug that only occurs on 64-bit versions of Windows OS.

From my layman point of view, I suggest that something is generally wrong with text and image rendering on Firefox 3.* when using a 64-bit Windows Vista/7.

[Grant Abraham (gabraham)]

I can replicate this bug with the cut-off text (as per comment #1 from Ryan Rubley). I am running Windows 7 RC 32-bit (build 7100). I also was able to replicate it on Windows Vista 32-bit on the same machine. Cleartype is on in both cases.

[Googulator (netrolller-3d)]

We already know the cause of this bug (the alpha-mask is incorrect for sub-pixel antialiased text), just don't know how to fix it (i.e., what the correct alpha mask would be).

[Ludovic-mozillamessaging (ludovic-mozillamessaging)]

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

[Wesley-johnston (wesley-johnston)]

(In reply to comment #37)
Have you tried doing an rgb->hsl conversion and using one of those numbers? I don't really understand what's going on there (pardon the bug spam if I'm way off track), but just glancing at the patch, it seems like lightness might be a better match.

[Sylvain Pasche (sylvain-pasche)]

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

[Ken-adcstudio (ken-adcstudio)]

the new DirectWrite backend in Cairo, and demonstrated in this build (http://www.basschouten.com/media/blogs/blog/warning.html) fixes the issue for me (on Vista x64).

[Micah Gersten (micahg)]

When Launchpad adds a link upstream, it should only be for the bugs currently selected in the upstream bug tasks.

On upstream bug https://bugzilla.mozilla.org/show_bug.cgi?id=499233
which is the upstream for bug 398128, Launchpad also added bug 195698 since it's considered an "Upstream Bug Watch". That however is incorrect as bug 195698 is upstream bug
https://bugzilla.mozilla.org/show_bug.cgi?id=356097 which is similar, but not the same.

[Dao (dao)]

This bug is about Windows only... there's no ClearType on Linux. Whoever's adding the links to launchpad, please stop it.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

(In reply to comment #51)
> This bug is about Windows only... there's no ClearType on Linux. Whoever's
> adding the links to launchpad, please stop it.

Apologies from Launchpad. There's an open bug for this and I just asked for the priority to be increased:
https://bugs.launchpad.net/malone/+bug/499113

[Micah Gersten (micahg)]

We're getting complaints upstream. Could this possible be made a higher priority? If it's not a difficult fix, I'd be happy to help.

https://bugzilla.mozilla.org/show_bug.cgi?id=363861#c51

[Micah Gersten (micahg)]

This bug just suffered from bug 491549

[Graham Binns (gmb)]

I think, if I'm understanding the problem right (and it's possible that I'm not because I've only just woken up) that this and the ever-so-delightful bug 491549 are actually symptoms of the same problem, namely that Launchpad treats all bug watches the same way instead of differentiating between those that are linked to a bug task (i.e. those that appear as 'assigned to foo.com bugzilla...' in the bug task table) and those not.

It's actually a relatively simple fix. The condition on line 870 of lib/lp/bugs/scripts/checkwatches.txt should be updated to also check that `bug_watch.bugtask is not None` and the tests should be updated accordingly. This will prevent syncing happening for all but those bug watches attached to bug tasks.

There's already work being done on checkwatches this cycle, so I wonder if we can include this in the mix, too.

[Graham Binns (gmb)]

I've marked bug 491549 as a dupe of this one and updated this bug's description since both bugs are actually the same problem manifesting in different ways.

[Deryck Hodge (deryck)]

Graham or Gavin, could one of you connect with Micah either here or IRC and do a discussion about what's involved in fixing this?

Cheers,
deryck

[Stream (stream)]

I think this is a bot, adding those urls in the WRONG place. Something have to be done about that in bugzilla.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

(In reply to comment #53)
> I think this is a bot, adding those urls in the WRONG place. Something have to
> be done about that in bugzilla.

As I said in comment #52, this is a Launchpad bug that's already open. It's adding matches anytime a bug # is mentioned in text.

[Micah Gersten (micahg)]

Is this a dupe of bug 296936?

[Micah Gersten (micahg)]

Maybe that older one should be a dupe of this since this includes pushing watches upstream as well.

[Graham Binns (gmb)]

I've marked bug 296936 as a dupe of this one; as Micah suggested they're the same bug, but this has more detail.

[Reed Loden (reed)]

I've removed the edit privileges from Launchpad's Bugzilla account on bugzilla.mozilla.org for now until this bug is fixed. Once that happens, please contact me to have them reinstated.

[Diogo Matsubara (matsubara)]

Fixed in devel r10318 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/10318>