300982 - ugly (bold) text, looks like a sub-pixel rendering of the text was drawn over itself

Status: VERIFIED WORKSFORME

(Core Graveyard :: GFX: Mac, defect)

Description

[Jesse Ruderman]

Hovering over links on http://planet.mozilla.org/, or highlighting and
unhighlighting words in the title of a Gmail message, can result in ugly text. 
I will attach a testcase based on planet.mozilla.org.

I am using:
* Mac OS X 10.4.2
* PowerBook (LCD screen might be significant)
* Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4)
Gecko/20050715 Firefox/1.0+

Comment 1

[Jesse Ruderman]

Attachment: simple testcase

While making this testcase, I noticed that text nodes are only affected if they
lie within a rectangle containing both links.

Comment 2

[Jesse Ruderman]

Attachment: screenshot of testcase

Comment 3

[Uri Bernstein]

I'm pretty sure this is a duplicate of bug 231253 (although the testcase here is
better).
Another duplicate is bug 261951, which is still UNCONFIRMED.
Jesse - I'll leave it to you to decide what (and if) to duplicate.

Comment 4

[Jesse Ruderman]

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

Comment 5

[Jesse Ruderman]

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

Comment 6

[Jesse Ruderman]

From the dups: also happens on http://www.groklaw.net/ (minimal testcase would
be similar to the one on this bug) and 
http://thomaso.best.vwh.net/examples/mozilla/z-index/index.html.

Comment 7

[Simon Fraser [no longer active]]

Can't repro in Camino.

Comment 8

[Jesse Ruderman]

Same here, can't repro in Camino (July 16 nightly).  I wonder what Camino is
doing differently.

Comment 9

[Jan Ruzicka]

The attached test case does not reproduce with FireFox 1.0.4 on 15" PowerBook G4
OS X 10.3.9 .

The groklaw exhibited the bug.

The bug is dependent on box enclosing the link and the text.
On different resizing diferent lines exhibited the issue.

Switching tabs cleared the ugly text.

Comment 10

[Juan Carlos Anorga]

In Firefox 1.0.5 I had to click and drag on one of the links in the testcase,
and then move my mouse from link to link to get the ugly text to appear. In
Deerpark Alpha 2 I just had to move my mouse from link to link.

Comment 11

[Gary Elshaw]

OS X 10.4.2 Deer Park Alpha 2

Using the example the changes to the text i see are a boldening of the last word
baz on the first line. Is this the change under discussion? Interestingly, if
you open the example in a separate tab, switch out and back again, the text has
returned to normal. Hope this helps somehow...

Comment 12

[Asa Dotzler [:asa]]

Jesse, or others on this bug, can you help us narrow down the regression window? 

Comment 13

[Uri Bernstein]

(In reply to comment #12)
> Jesse, or others on this bug, can you help us narrow down the regression window? 

This regressed between 2004-05-30 and 2004-06-21. Unfortunately, I couldn't find
any Mac builds between these two dates in the archives.

Comment 14

[Uri Bernstein]

Actually, that's not quite accurate. While I can't reproduce this with the
attached testcase on builds before 2004-06-21, the underlying bug must have
already been there: bug 231253 was filed on 2004-01-17, and the URL referred to
on that bug shows the problem on all the builds I tested (incl. Firefox 1.0).

Comment 15

[Uri Bernstein]

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

Comment 16

[Jesse Ruderman]

From the dup: sounds like this happens with CRT-style anti-aliasing as well as
LCD-style sub-pixel rendering.

Comment 17

[Jason McVetta]

Comment #16 is correct -- I have observed this on a CRT monitor.

Comment 18

[Josh Aas]

We might be drawing text over itself, and if that is the case then the alpha
from the antialiasing is probably just making it get darker and darker each time
we do it.

Comment 19

[Uri Bernstein]

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

Comment 20

[Uri Bernstein]

Adding "bold" to the summary so this is easier to find.

Comment 21

[Jesse Ruderman]

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

Comment 22

[Jesse Ruderman]

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

Comment 23

[Marc Drumm]

I have also encountered this bug in 1.5.0.1, and can provide an example on another web site if needed.

Comment 24

[Uri Bernstein]

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

Comment 25

[Chris Dolan]

Another very simple test case:
 1) Go to http://www.chrisdolan.net/bugreports/hovercolor.html
 2) mouseover the URL

=== Screenshots ===
Before: http://www.chrisdolan.net/bugreports/hovercolor_before.png
After: http://www.chrisdolan.net/bugreports/hovercolor_after.png

iMac G5, 10.4.6, LCD screen, FF 1.5.0.2 release

Comment 26

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 27

[Mike Schroepfer]

Josh any thoughts on a fix for this?

Comment 28

[Mike Connor [:mconnor]]

Would like a patch, but not a blocker.

Comment 29

[Josh Aas]

I don't know the code in question very well, so it would probably take me a while to figure it out. I'll try to take a look soon though.

Comment 30

[Kim Holburn]

I just noticed this in a different situation.  I was reading this page:
http://www.groklaw.net/article.php?story=20060626235954756 and I scrolled down to the text below.  

Notice that the word "generally" in the text below is underlined on the page.  I idly selected the text in the paragraph to the line above the underlined word "generally" then clicked under the line with "generally" on it (unselkecting the text) and the underlined word  became emboldened in the same way.

"Second, SCO claims that IBM has long known the newly identified material was at issue and therefore, the argument seems to go, SCO was not required to identify it in answers to interrogatories or in its Final Disclosures. (SCO Opp’n at 10-13.) SCO points to a magazine article in which it is quoted as claiming that Linux infringes SCO’s alleged UNIX copyrights. Of course, IBM has long known that SCO generally accuses Linux of infringement and has asserted a counterclaim against SCO seeking a declaration that IBM’s Linux activities do not infringe the copyrights."

(10.4.6 Firefox 1.5.0.4)

Comment 31

[Kim Holburn]

I just noticed another rather different example.  In this case the text is *italic* not underlined.  The URL is: http://www.eff.org/IP/faq/  and paragraph 4 is the one in question: 

The RIAA said that it only went after individual file sharers because you couldn't go after P2P system creators. After the Supreme Court's Grokster decision, shouldn't you stop going after music fans?

In this case the word "Grokster" is italicised and selecting text before the word "Grokster"  in that paragraph but including the first line and the line "Grokster" is on (line 2) makes the work Grokster exhibit the bug.

Comment 32

[Kim Holburn]

Another example from the same page.  In this case the text is not bold, underlined or italic but just red.  Paragraph 8 but it only works if you widen the page so that the red text "restricting devices that record from digital radio." is on the second line of the para and there is normal text before and after it.  The selecting and deselecting text from line 1 and parts of line 2 to the left (before) the red text makes the red text exhibit the problem (only in red of course).

Comment 33

[Uri Bernstein]

WFM with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061005 Minefield/3.0a1 ID:2006100515.

Probably fixed by Cocoa.

Comment 34

[Marco De Vitis]

Sorry Uri, but the bug is still present here, e.g. on the simple test case referenced in comment #25:
http://www.chrisdolan.net/bugreports/hovercolor.html

MacOS X 10.4.8, Firefox 2.0 RC2

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; it; rv:1.8.1) Gecko/20061003 Firefox/2.0

Seems like your versions is slightly newer, does it really contain such a difference? Can you please try the above link, hovering the mouse pointer on the URL contained in that page?

Comment 35

[Christopher Kintner]

I am using Firefox 2 RC2 (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0 ID:2006100316)

I can still reproduce the test case attached to this bug.

Comment 36

[Uri Bernstein]

(In reply to comment #34)

> MacOS X 10.4.8, Firefox 2.0 RC2
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; it; rv:1.8.1) Gecko/20061003
> Firefox/2.0

You're using a branch (Gecko 1.8.1, Fx 2.0) build, where the bug still exists.
I'm using a trunk (Gecko 1.9, Fx 3.0) build, where it was apparently fixed.

Comment 37

[Chris Dolan]

(In reply to comment #34)
> Sorry Uri, but the bug is still present here, e.g. on the simple test case
> referenced in comment #25:
> http://www.chrisdolan.net/bugreports/hovercolor.html
> 
> MacOS X 10.4.8, Firefox 2.0 RC2
> 
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; it; rv:1.8.1) Gecko/20061003
> Firefox/2.0
> 
> Seems like your versions is slightly newer, does it really contain such a
> difference? Can you please try the above link, hovering the mouse pointer on
> the URL contained in that page?

I'm the one that created that test case.  I can confirm that it's still broken in thew 1.5.x and 2.x branches, but fixed in the trunk (i.e. 3.x development).  So, Uri's right in declaring it fixed, even though it may be disappointing to have to wait for 3.0 to see that fix in day-to-day browsing...

Chris

Comment 38

[Jesse Ruderman]

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

Comment 39

[Robert Sayre]

I see this a lot. It looks really sloppy. We should fix this for 2.0.0.2.

Comment 40

[Josh Aas]

People have been taking cracks at fixing this for years... I bet it is fixed by cairo :)

Comment 41

[Robert Sayre]

(In reply to comment #40)
> People have been taking cracks at fixing this for years... I bet it is fixed by
> cairo :)

What is the "related code" you mentioned above?

Comment 42

[Robert Sayre]

leaving notes here for myself.

OK, so some research on the example shows that the rogue bold word is painted when the active link is. In the example, if you roll over "zappy zappy" and then "bar", the rogue bold word occurs when "bar" is flipped to red.

Comment 46

[Andy]

Attachment: Another Test Case: Negative left and text-indent values

From my testing, it appears as though this issue is related to the negative values used for text-indent and left values. Also, the bold font continues to get 'more bold', if you will - the more you roll over it.

To reproduce: roll over the 'departments' link several times.

Comment 49

[Tim]

Why is this bug marked RESOLVED WORKSFORME when it's clearly still a problem and easily reproducible?

Comment 50

[Chris Dolan]

(In reply to comment #49)
> Why is this bug marked RESOLVED WORKSFORME when it's clearly still a problem
> and easily reproducible?

Because it's fixed on the trunk.  See comment #37 above.
Chris

Comment 51

[Tim]

Then it should be marked as fixed and have 3.x as the target version.
It shouldn't be marked with a misleading status and have people read through the comments to realize what really happened.

Comment 52

[Logan Shaw]

(In reply to comment #50)
> (In reply to comment #49)
> > Why is this bug marked RESOLVED WORKSFORME when it's clearly still a problem
> > and easily reproducible?

> Because it's fixed on the trunk.  See comment #37 above.

If it is fixed, then it should be marked FIXED.  According to the description of the "Status" field, WORKSFORME means "all attempts at reproducing this bug were futile".

The reason I'm bothering to comment about this is that I thought the same thing as well.  When there are recent reports of a bug (like, today) and those reports keeping getting marked as a duplicate of a bug whose status WORKSFORME, it just looks bad.  WORKSFORME implies it cannot be reproduced, but when new bugs keep showing up, that implies it can be reproduced.

Comment 53

[Jesse Ruderman]

WORKSFORME is also used for "we can reproduce in an old version, but we can't reproduce in a new version, and we don't know which code change fixed it".  https://bugzilla.mozilla.org/page.cgi?id=fields.html#status lies.