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

VERIFIED WORKSFORME

Status

Core Graveyard
GFX: Mac
VERIFIED WORKSFORME
12 years ago
8 years ago

People

(Reporter: Jesse Ruderman, Assigned: Josh Aas)

Tracking

Trunk
PowerPC
Mac OS X
Bug Flags:
blocking1.8b5 -
blocking-aviary1.5 -
blocking1.9 -
wanted1.9 +
blocking1.8.1 -
blocking1.8.1.2 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
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+
(Reporter)

Comment 1

12 years ago
Created attachment 189495 [details]
simple testcase

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

Comment 2

12 years ago
Created attachment 189496 [details]
screenshot of testcase
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.
(Reporter)

Comment 4

12 years ago
*** Bug 261951 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 5

12 years ago
*** Bug 231253 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 6

12 years ago
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

12 years ago
Can't repro in Camino.
(Reporter)

Comment 8

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

Comment 9

12 years ago
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

12 years ago
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.
(Reporter)

Updated

12 years ago
Flags: blocking1.8b4?

Comment 11

12 years ago
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

12 years ago
Jesse, or others on this bug, can you help us narrow down the regression window? 
(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.
Keywords: regression
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).
Keywords: regression
*** Bug 301789 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Flags: blocking1.8b4? → blocking1.8b4-
(Reporter)

Comment 16

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

Comment 17

12 years ago
Comment #16 is correct -- I have observed this on a CRT monitor.
(Assignee)

Comment 18

12 years ago
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.
(Reporter)

Updated

12 years ago
Flags: blocking-aviary1.5?

Updated

12 years ago
Flags: blocking-aviary1.5? → blocking-aviary1.5-

Updated

12 years ago
Flags: blocking1.9a1?
*** Bug 312797 has been marked as a duplicate of this bug. ***
Adding "bold" to the summary so this is easier to find.
Summary: ugly text, looks like a sub-pixel rendering of the text was drawn over itself → ugly (bold) text, looks like a sub-pixel rendering of the text was drawn over itself
(Reporter)

Comment 21

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

Updated

12 years ago
Flags: blocking1.8.1?
(Reporter)

Comment 22

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

Comment 23

11 years ago
I have also encountered this bug in 1.5.0.1, and can provide an example on another web site if needed.
*** Bug 335727 has been marked as a duplicate of this bug. ***

Comment 25

11 years ago
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
*** Bug 340766 has been marked as a duplicate of this bug. ***

Comment 27

11 years ago
Josh any thoughts on a fix for this?
Would like a patch, but not a blocker.
Flags: blocking1.8.1? → blocking1.8.1-
(Assignee)

Comment 29

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
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).
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME

Comment 34

11 years ago
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

11 years ago
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.
(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

11 years ago
(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
(Reporter)

Comment 38

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

Comment 39

11 years ago
I see this a lot. It looks really sloppy. We should fix this for 2.0.0.2.
Flags: blocking1.8.1.2?
(Assignee)

Comment 40

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

Comment 41

11 years ago
(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?

Updated

11 years ago
Flags: blocking1.8.1.2? → blocking1.8.1.2-

Comment 42

11 years ago
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.
Duplicate of this bug: 370754
Duplicate of this bug: 374691
Duplicate of this bug: 377657

Comment 46

10 years ago
Created attachment 263333 [details]
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.
(Reporter)

Updated

10 years ago
Duplicate of this bug: 384506
(Reporter)

Updated

10 years ago
Duplicate of this bug: 385051

Comment 49

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

Comment 50

10 years ago
(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

10 years ago
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

10 years ago
(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.
(Reporter)

Comment 53

10 years ago
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.
Status: RESOLVED → VERIFIED
Flags: wanted1.9+
Whiteboard: [wanted-1.9]

Updated

9 years ago
Duplicate of this bug: 356906
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.