654570 - Black bars / box when scrolling down a large page

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Allan Gardner (:Mathnerd314)]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110503 Firefox/6.0a1
Build Identifier: 

Scrolling down about halfway through the page shows a black box instead of the expected page content.

Reproducible: Always

Steps to Reproduce:
1. Open a clean profile to the page
2. Hold PgDn until a flash of black appears
3. Scroll back up and see a black bar

Actual Results:  
Black bar

Expected Results:  
Normal page content

Comment 1

[Allan Gardner (:Mathnerd314)]

from about:support
Graphics
Adapter Description	VIA Chrome9 HC3 IGP
Vendor ID	1106
Device ID	1122
Adapter RAM	Unknown
Adapter Drivers	S3gIGP
Driver Version	6.14.10.213
Driver Date	4-17-2009
Direct2D Enabled	Blocked on your graphics card because of unresolved driver issues.
DirectWrite Enabled	false (0.0.0.0)
WebGL Renderer	(WebGL unavailable)
GPU Accelerated Windows	0/1

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

Confirmed against Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110504 Firefox/6.0a1 ID:20110504030604 & Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 ID:20110413222027 with HWA turned off.

Also reproducible if you unfocus Fx/switch to another Application and then back: the whole Content View is black.

Comment 3

[Alice0775 White]

Confirmed HWA turned off:
http://hg.mozilla.org/mozilla-central/rev/c3c4c902e9cd
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110504 Firefox/6.0a1 ID:20110504030604

Regression window(m-c hourly):
Works:
http://hg.mozilla.org/mozilla-central/rev/62e95bdbae61
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020133437
Fails:
http://hg.mozilla.org/mozilla-central/rev/f780f3d3add9
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020135237
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=62e95bdbae61&tochange=f780f3d3add9
Regressed by:
f780f3d3add9	Jeff Muizelaar — Bug 604168. pixman: Update to f6ab20ca6604739b82311fc078d6ce850f43adc0

Comment 4

[Siarhei Siamashka]

Problem also confirmed in linux.

pixman-0.22.0 - black bars
pixman-0.20.2 - black bars
pixman-0.18.4 - striped artefacts
pixman-0.16.6 (with cherry picked 78778e5963c948de5ce5f7c5a2a3bb9f279a8eda and e841c556d59ca0aa6d86eaf6dbf061ae0f4287de) - striped artefacts

Now bisecting this "black bars" -> "striped artefacts" transition.

Comment 5

[Siarhei Siamashka]

Black bars started to show after http://cgit.freedesktop.org/pixman/commit/?id=1cc750ed92a936d84b47cac696aaffd226e1c02e

Previous behavior was not correct either. Apparently some 16.16 fixed point overflow happens for this particular page, causing problems (wrong rendering with older pixman versions, no rendering at all with more recent).

Comment 6

[Siarhei Siamashka]

Attachment: backtrace.txt

Backtrace from the problematic pixman 'pixman_image_composite32' call.

It is interesting that src_y=36162, and the transformation matrix has a huge translate on y axis:
{65536, 0,     0},
{0,     65536, -1925054464},
{0,     0,     65536}

I guess that this out of range src_y and translate in the transformation matrix were supposed to cancel each other, but unfortunately pixman (and XRENDER) use 16.16 fixed point representation and bad things may happen if coordinates or values exceed ~32K limit.

Comment 7

[Siarhei Siamashka]

(In reply to comment #5)
> Black bars started to show after
> http://cgit.freedesktop.org/pixman/commit/
> ?id=1cc750ed92a936d84b47cac696aaffd226e1c02e
> 
> Previous behavior was not correct either.

A correction to this statement. Previous browser behavior with older pixman was not correct only when using system cairo (1.10.2). Which indicates that mozilla's cairo is not well synchronized with upstream at least for this part of code. Though this does not come as a big surprise.

Anyway, one rationale for not considering 16.16 fixed point limitation a serious problem for pixman was that ~32Kx32K sized images consume too much memory and are not very practical anyway. Still there are some uses for large images too, for example for working with huge high resolution maps [1]. And in this particular case the issue is related to NORMAL repeated background (a narrow horizontal image having width = 1800, height = 7 and replicated over all the web page). Repeated images do not take too much space in memory, but are supposed to span infinitely and be usable with any arbitrary translate. So something could be reviewed regrading the range of acceptable input arguments for pixman, also with the relevant tests added.

Right now there may be problems with translations exceeding 32K (or even 64K as cairo seems to be doing some tricky things to distribute translation between the matrix and offset [2]). What's particularly bad is that there are no checks for potential overflows in '_cairo_fixed_16_16_from_double' or similar code, so the bugs are not caught early, but propagated further to cause some weird problems later.

As a quick fix for mozilla, maybe just some newly added guard checks could be removed from the beginning of pixman_image_composite32 in order not to reject some operations and revert to previous behavior.

1. http://comments.gmane.org/gmane.comp.graphics.pixman/1017
2. http://cgit.freedesktop.org/cairo/tree/src/cairo-image-surface.c?id=1.10.2#n1541

Comment 8

[Siarhei Siamashka]

Attachment: hackish-workaround-for-mozilla-bug-654570.diff

But probably it's better to apply some fix to cairo instead of this. Just because cairo already tries to tweak parameters and bring them into 16-bit range. Moreover, such tweak is likely to be also needed for XRENDER backend.

Comment 9

[Siarhei Siamashka]

Can anybody assess severity/priority of this bug? At least it is clear what is happening there and the problem can be patched.

Comment 10

[Siarhei Siamashka]

This bug got worse after upgrading cairo to 1.10 (bug 562746) and the attached patch for pixman is not enough to fix it anymore. Looks like now bisecting cairo might be a good idea.

Comment 13

[Robert Claypool]

Is there anything relatively easy to do to get this bug back on the radar? Since there is no crash, there can be no crash dump, but there might be something.

Comment 14

[LegNeato]

This is not Firefox 7 specific so we are not tracking this.

Jeff, feel free to triage as you feel fit.

Comment 15

[Chris Coyier]

I am getting *lots* of people emailing me that this "black bars" issue affects http://css-tricks.com/ . Seems to just be Windows and Firefox 6/7/8. 

Example: http://img823.imageshack.us/img823/7859/csstricks.png

Is there something I can do until the bug is fixed?

Comment 16

[Eric Amidon]

I'm with Chris...is there a best practice we can be made aware of that will help us to avoid this problem?

Comment 17

[anthony_m9221]

I was one who reported black bars on Chris' http://css-tricks.com/, after seeing if I could get his site to display correctly for me. My findings appeared to indicate that something changed between FF5 and FF6, to make the black bars appear. FF5 is the last version to display the site correctly when hardware acceleration is enabled. However, I discovered that with HA disabled, the black bars don't appear anymore in the more recent FF versions. Furthermore, with HA enabled, the black bars vanished when I resized my screen below 1024 px. That's probably specific to his site's CSS, but I couldn't figure out what rules if any eliminated the bars. Overall, I'm not sure what to make of the black bars (I have no understanding of Firefox source)...I just thought I'd share my findings from a hobbyist web dev's point of view, and see if it helps...

Comment 18

[Chris Coyier]

For the record, this was solved on CSS-Tricks by reducing the font size of a particular element. BAD = 120px, GOOD = 98px. Apparently the max is 99px before the black bars started showing up.

Comment 19

[Eric Amidon]

Awesome. Thanks so much for sharing. What element was it if I may ask?

Comment 20

[Chris Coyier]

.comment-bubble in current design

Comment 21

[Alice0775 White]

The problem still exist.
http://hg.mozilla.org/mozilla-central/rev/abb39d1df815
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121130 Firefox/20.0 ID:20121130030747

Please backed out the offending patch of bug 604168.

Comment 22

[Nicola R]

recent versions of firefox-27a1 for linux x86_64 are affected too. It's a very recent problem: since the nightly released on 20th October. Instead on windows everything is ok.

Comment 23

[Justin [:JW_SoftvisionQA]]

I can not reproduce this on Mozilla/5.0 (Windows NT 6.3; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0

I will close out this issue. If anyone is able to reproduce this issue please feel free to ope it back up.