User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070124 Minefield/3.0a2pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070124 Minefield/3.0a2pre The fonts has changed since about one day. Some letters on a page have bold parts. It is difficult to explain what I mean: look at the screenshot I'll attach. The g of "given" and the words "shipping by". It happens randomly. When I wipe with another window over the page or when I change the font-size with ctrl+mousewheel, they will redraw better. Probably caused by Bug 333659 or Bug 367177. Can't tell more about it. Reproducible: Always Steps to Reproduce: 1. Go to e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=368029 2. Look at the font Actual Results: Look at screenshot. Expected Results: Normal font without bold parts.

Confirming. I've noticed this too, it some fonts also seem to be incorrectly italicised (maybe they aren't being italicised but they appear to be).

To me, this doesn't look like an actual italicizing per se. It's more like the upper or lower half of the glyph is just being shifted over by 1 pixel. If I select/deselect the text, the glyph fixes itself, which suggests it's some rounding error which gets fixed when selecting the text (which I'm guessing forces some kind of recalculation?). It's the same issue with the "bolding", just another manifestation of the same core problem I'm guessing.

[image taken from: http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox] another screenshot showing the 1 pixel shifting (to the left)

I believe the bug is trigger by: * scrolling * tooltips over text * absolute positioned elements witch cover text that became hidden * dragging other Chrome windows over text

I see the same thing as Ryan in comment 3 quite often.

(In reply to comment #4) > another screenshot showing the 1 pixel shifting (to the left) The shift with that page is to the _right_ (as seen from your screenshot). [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070305 SeaMonkey/1.5a] (nightly) (W2Ksp4) Confirming, with SeaMonkey: I can reproduce comment 4. FWIW, I noticed that on <http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey>, the background area shifts to the _left_ instead.

(In reply to comment #8) > The shift with that page is to the _right_ (as seen from your screenshot). ah yes! to the right ;-)

(In reply to comment #8) > <http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey>, [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070504 SeaMonkey/1.5a] (nightly) (W2Ksp4) Actually, depending on zoom setting, which part of the screen moves and in which direction can be different: anyway, bug still there.

Anyone have steps to reliably reproduce?

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4) Robert, the shift on the tinderbox pages is (still) 100% reproducible...

I can't reproduce this anymore on tinderbox. Are other still seeing it?

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/2007061502 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) Bug still there, with new SMv2.0 trunk. On <http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey>.

(In reply to comment #15) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/2007061602 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) (At Zoom=200%) I can still reproduce quite easily.

Bug 338921 appears to be very similar to this one.

punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.

I haven't seen this for quite some time. Anyone else?

Me neither.

V.WorksForMe: it seems the issues were fixed "step by step" during the last 3-4 months... :-) (Even if not having a reliable (test)case makes it hard to be 100% sure.)