Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in mozilla17

Status

()

Core
Graphics
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: tomer, Assigned: karlt)

Tracking

({regression})

10 Branch
mozilla17
x86
Linux
regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
Created attachment 580649 [details]
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

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

Comment 2

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

Comment 3

6 years ago
See also: http://whatsup.org.il/index.php?name=PNphpBB2&file=viewtopic&t=58460
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?
Created attachment 600555 [details]
partially simplified testcase

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

Comment 7

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

Comment 8

6 years ago
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.
Created attachment 600612 [details]
more reduced testcase
Attachment #600555 - Attachment is obsolete: true
(Reporter)

Comment 11

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

Comment 12

5 years ago
Created attachment 609018 [details]
another site screenshot

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

Updated

5 years ago
Duplicate of this bug: 775203
(Assignee)

Comment 14

5 years ago
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
}
Component: Layout: View Rendering → Graphics
(Assignee)

Updated

5 years ago
Assignee: nobody → karlt
Status: NEW → ASSIGNED
(Assignee)

Comment 15

5 years ago
Created attachment 647346 [details] [diff] [review]
use precise region extents instead of loose clip extents for clip rect
(Assignee)

Comment 16

5 years ago
Created attachment 647812 [details] [diff] [review]
reftest
(Assignee)

Updated

5 years ago
Attachment #647346 - Flags: review?(jmuizelaar)
(Assignee)

Comment 17

5 years ago
clip extents are the intersection of extents of each clip path applied.
(Assignee)

Comment 18

5 years ago
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
Keywords: regression
(Assignee)

Comment 19

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/95977d7f113d
Flags: in-testsuite+
Whiteboard: [leave open]
https://hg.mozilla.org/mozilla-central/rev/95977d7f113d
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+
(Assignee)

Comment 23

5 years ago
(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
(Assignee)

Comment 24

5 years ago
Fix for this bug pushed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b3891772df8
Whiteboard: [leave open]
https://hg.mozilla.org/mozilla-central/rev/5fb4e694c64d
https://hg.mozilla.org/mozilla-central/rev/8b3891772df8
Status: ASSIGNED → RESOLVED
Last Resolved: 5 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
> https://hg.mozilla.org/integration/mozilla-inbound/rev/5fb4e694c64d

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