Closed
Bug 709477
Opened 13 years ago
Closed 12 years ago
random bolder words appear after scrolling on whatsup.co.il
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla17
People
(Reporter: tomer, Assigned: karlt)
References
()
Details
(Keywords: regression)
Attachments
(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: 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•13 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•13 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•13 years ago
|
||
Comment 4•13 years ago
|
||
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?
Comment 7•13 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•13 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.
Comment 10•13 years ago
|
||
Attachment #600555 -
Attachment is obsolete: true
Reporter | ||
Comment 11•13 years ago
|
||
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•13 years ago
|
||
I was able to reproduce the same issue on other site as well.
http://seodoityourself.co.il/?p=2864
Assignee | ||
Comment 14•12 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•12 years ago
|
Assignee: nobody → karlt
Status: NEW → ASSIGNED
Assignee | ||
Comment 15•12 years ago
|
||
Assignee | ||
Comment 16•12 years ago
|
||
Assignee | ||
Updated•12 years ago
|
Attachment #647346 -
Flags: review?(jmuizelaar)
Assignee | ||
Comment 17•12 years ago
|
||
clip extents are the intersection of extents of each clip path applied.
Assignee | ||
Comment 18•12 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•12 years ago
|
||
Flags: in-testsuite+
Whiteboard: [leave open]
Comment 20•12 years ago
|
||
Comment 21•12 years ago
|
||
Karl, did you mean to disable 468496-1.html?
Comment 22•12 years ago
|
||
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•12 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•12 years ago
|
||
Fix for this bug pushed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b3891772df8
Whiteboard: [leave open]
Comment 25•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/5fb4e694c64d
https://hg.mozilla.org/mozilla-central/rev/8b3891772df8
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Comment 26•12 years ago
|
||
(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.
Description
•