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+
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.
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.
*** Bug 261951 has been marked as a duplicate of this bug. ***
*** Bug 231253 has been marked as a duplicate of this bug. ***
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.
Can't repro in Camino.
Same here, can't repro in Camino (July 16 nightly). I wonder what Camino is doing differently.
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.
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.
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...
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.
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).
*** Bug 301789 has been marked as a duplicate of this bug. ***
From the dup: sounds like this happens with CRT-style anti-aliasing as well as LCD-style sub-pixel rendering.
Comment #16 is correct -- I have observed this on a CRT monitor.
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.
*** Bug 312797 has been marked as a duplicate of this bug. ***
Adding "bold" to the summary so this is easier to find.
*** Bug 322029 has been marked as a duplicate of this bug. ***
*** Bug 325531 has been marked as a duplicate of this bug. ***
I have also encountered this bug in 22.214.171.124, and can provide an example on another web site if needed.
*** Bug 335727 has been marked as a duplicate of this bug. ***
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 126.96.36.199 release
*** Bug 340766 has been marked as a duplicate of this bug. ***
Josh any thoughts on a fix for this?
Would like a patch, but not a blocker.
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.
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 188.8.131.52)
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.
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).
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.
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 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.
(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
*** Bug 363300 has been marked as a duplicate of this bug. ***
I see this a lot. It looks really sloppy. We should fix this for 184.108.40.206.
People have been taking cracks at fixing this for years... I bet it is fixed by cairo :)
(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?
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.
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.
Why is this bug marked RESOLVED WORKSFORME when it's clearly still a problem and easily reproducible?
(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
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.
(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.
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.