709477 - random bolder words appear after scrolling on whatsup.co.il

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Tomer Cohen :tomer]

Attachment: Screenshot - Please note the bolder text.

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: http://whatsup.org.il/index.php?name=PNphpBB2&file=viewtopic&t=57990)
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?

Comment 1

[Meir Kriheli]

No one complained, but I have those issues as well for quite some time (FF 8.0.1 on ArchLinux).

Comment 2

[Tomer Cohen :tomer]

Seems that this issue is very similar to the behavior described here: https://support.mozilla.com/en-US/kb/Some%20text%20shows%20up%20bold%20after%20upgrade

Maybe it could be solved by changing fonts, but it should not happen in multiple [clean] profiles!

Comment 3

[Tomer Cohen :tomer]

See also: http://whatsup.org.il/index.php?name=PNphpBB2&file=viewtopic&t=58460

Comment 4

[Jonathan Kew [:jfkthame]]

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.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: partially simplified testcase

Simplified from http://whatsup.org.il/index.php?name=PNphpBB2&file=viewtopic&t=57990

Comment 7

[Yotam Benshalom]

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.

Comment 8

[Dotan Porat]

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.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

More "here too" reports are not helpful.

Comment 10

[Timothy Nikkel (:tnikkel)]

Attachment: more reduced testcase

Comment 11

[Tomer Cohen :tomer]

Attachment: WordPress RTL screenshot

I am able to reproduce this behavior on plain WordPress installation with default theme (twentyeleven), although it is less visible than on whatsup.org.il.

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.

Comment 12

[Tomer Cohen :tomer]

Attachment: another site screenshot

I was able to reproduce the same issue on other site as well. 
http://seodoityourself.co.il/?p=2864

Comment 14

[Karl Tomlinson (:karlt)]

This code is assuming that extents on a cairo_clip_t->path are accurate when the clip region is a rectangle
http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/cairo/src/cairo-xlib-surface.c#4816
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
}

Comment 15

[Karl Tomlinson (:karlt)]

Attachment: use precise region extents instead of loose clip extents for clip rect

Comment 16

[Karl Tomlinson (:karlt)]

Attachment: reftest

Comment 17

[Karl Tomlinson (:karlt)]

clip extents are the intersection of extents of each clip path applied.

Comment 18

[Karl Tomlinson (:karlt)]

Try results for reftest:
https://tbpl.mozilla.org/?tree=Try&rev=ef1c1d2ce470
https://tbpl.mozilla.org/?tree=Try&rev=de5f83a4efa8
For patch:
https://tbpl.mozilla.org/?tree=Try&rev=47e0b459eb76

Comment 19

[Karl Tomlinson (:karlt)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/95977d7f113d

Comment 20

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/95977d7f113d

Comment 21

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Karl, did you mean to disable 468496-1.html?

Comment 22

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 23

[Karl Tomlinson (:karlt)]

(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 https://hg.mozilla.org/integration/mozilla-inbound/rev/5fb4e694c64d

Comment 24

[Karl Tomlinson (:karlt)]

Fix for this bug pushed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b3891772df8

Comment 25

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/5fb4e694c64d
https://hg.mozilla.org/mozilla-central/rev/8b3891772df8

Comment 26

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(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
> https://hg.mozilla.org/integration/mozilla-inbound/rev/5fb4e694c64d

Thanks for fixing :)