Closed Bug 709477 Opened 8 years ago Closed 8 years ago

random bolder words appear after scrolling on


(Core :: Graphics, defect)

10 Branch
Not set





(Reporter: tomer, Assigned: karlt)




(Keywords: regression)


(6 files, 1 obsolete file)

Sometimes, after using the mouse scroller, some text on this site appears bolder than other words, while probably nothing was changed. 

I'm using Ubuntu on a Dell Inspiron 1525 laptop, and have this issue for a long time. It might be something with the display adapter, but it happens only using Firefox.

Steps to reproduce:
a. Enter the site and navigate to a random topic on the forum. (The following one is a good example:
b. Scroll up and down using the mouse wheel, for the weird effect to happen.

Screenshot attached. (Rendered with an Aurora build)

Meir, the webmaster of this site is CC'ed to this issue. Meir, do you know if some other users have similar complains?
No one complained, but I have those issues as well for quite some time (FF 8.0.1 on ArchLinux).
Seems that this issue is very similar to the behavior described here:

Maybe it could be solved by changing fonts, but it should not happen in multiple [clean] profiles!
A couple of observations, in case they help anyone figure out what could be going wrong:

- The bad rendering does not necessarily start at a word boundary, or even between characters; it begins at some arbitrary place along the line, possibly even in the middle of a glyph. I think this suggests a graphics-level rather than layout/text-level issue.

- It always seems to end, however, when it reaches a transition between Hebrew and English (or vice versa) - i.e. a direction-run boundary - although it _may_ also end even where there isn't such a boundary. This could hint at a layout/text issue rather than graphics. Hmmm....

- The "bolder" text looks like it has been painted multiple times, judging by the intense color (antialiasing) fringes on the glyphs; that would be the result of partially-transparent pixels being repainted several times without erasing.
I see this with scrollbar scrolling as well, on Ubuntu 11.10, on the URL in comment 0.  (I don't have a working mousewheel.)

The right edge (the straight line edge) of where the problem happens seems to also be the edge of where there's some laggy scrolling.  My eyes aren't good enough to be sure which side is lagging, though, but I *think* it's the right side of the line that's lagging.

So my guess would be that something related to the laggy scrolling is causing double-painting of things on the left side of the line whose frames also extend to the right of the line -- perhaps because we're failing to clip properly when trying to repaint only what's to the right of the line?
This happens here too, on ubuntu 11.10 64 bit, firefox 12.0a2 (2012-02-22). The hardware is Dell studio xps laptop with nvidia 9500m card, using proprietary driver. Please let me know if I can help with further information for diagnostics.
Component: Layout: Text → Layout: View Rendering
QA Contact: layout.fonts-and-text → layout.view-rendering
This happens here too, on mint 12, firefox 12.0a2 (2012-02-22). The hardware is Lenovo thinkpad t43p with ati graphic card with open source driver. thanks.
More "here too" reports are not helpful.
Attached file more reduced testcase
Attachment #600555 - Attachment is obsolete: true
I am able to reproduce this behavior on plain WordPress installation with default theme (twentyeleven), although it is less visible than on

Steps to reproduce: place cursor inside the comments textarea and roll the mouse wheel up and down without leaving the keyboard focus from the textarea.
Attached image another site screenshot
I was able to reproduce the same issue on other site as well.
Duplicate of this bug: 775203
This code is assuming that extents on a cairo_clip_t->path are accurate when the clip region is a rectangle
But that is not the case when the clip path has a prev path.
The rectangle is the intersection of the paths.

(gdb) p clip_region->rgn.extents
$69 = {
  x1 = 8, 
  y1 = 137, 
  x2 = 291, 
  y2 = 238
(gdb) p *clip_extents
$70 = {
  x = 8, 
  y = 137, 
  width = 750, 
  height = 342
Component: Layout: View Rendering → Graphics
Assignee: nobody → karlt
Attached patch reftestSplinter Review
Attachment #647346 - Flags: review?(jmuizelaar)
clip extents are the intersection of extents of each clip path applied.
Flags: in-testsuite+
Whiteboard: [leave open]
Karl, did you mean to disable 468496-1.html?
Comment on attachment 647346 [details] [diff] [review]
use precise region extents instead of loose clip extents for clip rect

Review of attachment 647346 [details] [diff] [review]:

Sorry this took so long.
Attachment #647346 - Flags: review?(jmuizelaar) → review+
(In reply to :Ms2ger from comment #21)
> Karl, did you mean to disable 468496-1.html?

No I didn't sorry.  Thanks for catching that.

Restored in
Fix for this bug pushed:
Whiteboard: [leave open]
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
(In reply to Karl Tomlinson (:karlt) from comment #23)
> (In reply to :Ms2ger from comment #21)
> > Karl, did you mean to disable 468496-1.html?
> No I didn't sorry.  Thanks for catching that.
> Restored in

Thanks for fixing :)
You need to log in before you can comment on or make changes to this bug.