User Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0a1) Gecko/20110711 Firefox/8.0a1 Build ID: 20110711030829 Actual results: Background-images are not being repeated after ~33500px

I can reproduce if I disabled HWA. http://hg.mozilla.org/mozilla-central/rev/931f06b80727 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110713 Firefox/8.0a1 ID:20110713030741 Regression window with force HWA turned off(m-c hourly): Works: http://hg.mozilla.org/mozilla-central/rev/dad825159748 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110527 Firefox/7.0a1 ID:20110527011902 Fails: http://hg.mozilla.org/mozilla-central/rev/04e8d0b481bc Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110527 Firefox/7.0a1 ID:20110527081111 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dad825159748&tochange=04e8d0b481bc Regressed by: Bug 562746 - Update cairo to 1.10

This seems like a correctness regression we should track for 7 and 8....

This only seems to impact cairo-gdi

(In reply to tpv from comment #0) > Background-images are not being repeated after ~33500px How did you run into this problem? Was it on some content on the web?

I can't reproduce this on FF9 anymore :( It would be good to get a regression window on the thing that fixed it.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #5) > I can't reproduce this on FF9 anymore :( It would be good to get a > regression window on the thing that fixed it. Did you disable HWA? I can reproduced with HWA off on http://hg.mozilla.org/mozilla-central/rev/f69a10f23bf3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110818 Firefox/9.0a1 ID:20110818030747

Yes, even with HWA disabled I still can't reproduce this any more.

The reason this happens is because we pass in a src_y to pixman_image_composite32 that fails the IS_16BIT test in analyze_extents.

This problem exists on older versions of FF it's just rarer.

Jeff, is this something we need to worry about for Firefox 7? I doubt it but would like your opinion.

I can still see this on http://muarchives.missouri.edu/c-rg22-s41.html with FF10. There are some possible dupes of this as bug 690789 and bug 685174.

This bug is not limited to "large divs" but will also manifest itself on the body and on table cells (probably more, but those two are the cases I tested ).

This makes pages with dark background-image and light text partly unreadable, e.g. http://armageddonconspiracy.co.uk/

background image issue no longer visible on firefox 8 for mac (OS Lion 10.7.2)

Confirm the bug. See also below http://beoff.ru/?p=22587 page breaks. Page more 32768 px User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0 windows xp - 32 bit Screenshot of problem area site: <a href='http://postimage.org/image/uxy2w4ytn/' target='_blank'><img src='http://s9.postimage.org/uxy2w4ytn/bug.jpg' border='0' alt="bug" /></a> Sorry for bad English

I can also confirm this on Mozilla/5.0 (Windows NT 6.2; WOW64; rv:11.0a1) Gecko/20111116 Firefox/11.0a1 An example of affected page is http://sfw.org.ua/1148988189-fotografii-novinok-frankfurtskogo-motorshou.html. On the lower third of the page the background image disappears. Could this bug possibly be related to bug 591822? Both have similar 32k+ pixel problems.

Does not work at all the sides, not only down (in userChrome/userContent too).

See also [url=http://www.imdb.com/features/video/browse/trailer/]IMDB[/url] http://postimage.org/image/bdb55z5kl In Firefox seen, in other browsers shows no errors

[Triage Comment] Is there any reason to believe that this will occur with any greater frequency in FF9/10 than in FF8?

No

(In reply to j.j. from comment #28) > No Given that, and my understanding of the user-effect of this bug, we'd consider taking a low-risk fix for this but would not block shipping FF9/10. Minusing the tracking flags.

Duplicate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=692350 I found this problem too: http://s017.radikal.ru/i422/1112/4c/f3980c837070.jpg Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Windows XP (32 bit) It fails starts from version 7.0. In Firefox 6.0 no problems.

Temporary fixed with js and background-position. Will only works with a repeatable background, of course. We managed to center the background on the visible part on the div (visible = for human eyes on a screen). Someone asked if this bug have a real impact on website dev : yes, very large divs are useful for example if you want to display a draggable map.

Also seeing this on Fennec Native when rendering timecube.com (I assume it's the same bug since the background disappears at around 32700 pixels down). Should the affected platform/version/tracking flags/whatnot be updated?

Requesting tracking-fennec as per IRC discussion with mfinkle; this affects fennec as well.

I ran into this problem with my website: http://hanamiti.com.ua/segmented-paintings/ I have a very long list of product images here, and the background image stops showing at about half the height (background color displays fine if set). FireBug CSS panel show that the height of this block is 0. Mozilla developers, please fix this issue! Best regards

(In reply to Alex Keybl [:akeybl] from comment #27) > [Triage Comment] > Is there any reason to believe that this will occur with any greater > frequency in FF9/10 than in FF8? Yes. Low-risk fix ::: Just did (this week) a very late upgrade from ff 5.x to 10.x because new add ons disabled if incompatible. Just realized you can option to not disable during ff install. Using 10.0.2 on windows XP. This background image not loading in firefox issue is a very critical issue. <body background="http://www.anywebsite.com/image.jpg"> My HTML with css website that has simple but very long lists (print to pdf is 25+ pages). After 12 years on the internet no longer loads the background image in firefox. Very critical issue that needs to be fixed asap. This is very basic html that needs to work in ff. Videos and html5 videos are massive files. My 25 page length pages are a necessity for user experience. Twitter and google images have almost infinate scroll to load more pages. Background image not loading is the type of very significant bug that breaks the internet for no reason. Users of my lists do not visit list pages that are spread to multiple pages. My webpages must be singular long pages. Webpages require background images for design. ff does not load background images. This is a significant bug issue.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9) > This problem exists on older versions of FF it's just rarer. Not so rare. Using 10.0.2 on windows XP. Significant issue. XP users just fell below 50% as of August 2011. http://www.techspot.com/news/44902-windows-xp-usage-finally-falls-below-50-mark.html

(In reply to Boris Zbarsky (:bz) from comment #2) > This seems like a correctness regression we should track for 7 and 8.... occurrence continues in 10

occurs in Firefox 11.

occurs in Firefox 12 beta.

We don't need any further updates on this not being fixed, this bug is still open indicating that it is not fixed.

Nom'ing as fennec blocker. It affects a number of long pages in fennec.

What about cairo 1.12?

We're minusing this because we're not convinced that it's the same bug (cairo-gdi vs cairo-image). I'm deduping bug 752799 because that's the mobile version of this bug.

Occurs in Firefox 13. https://www.allegromicro.com/en/Sample-And-Buy/Contact-Sales.aspx

(In reply to rcouture from comment #52) > Occurs in Firefox 13. > https://www.allegromicro.com/en/Sample-And-Buy/Contact-Sales.aspx URL above is HTTP and not HTTPS. And yes, is still reproducible with both Firefox 13 and latest Nightly (on Windows XP at least).

I also see this with Firefox 15.0 and with the example links give in the previous posts (e.g. http://hanamiti.com.ua/segmented-paintings/).

This is a critical bug for us! It is preventing our products to run on Mozilla. Currently we have marked Mozilla as not-supported browser due to this issue. Is there any intention to fix it?

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 562746.

Maybe updating to cairo 1.12.8 will fix it (bug 739096).

Still in Firefox 18. Example page: http://halbtagsblog.de/schule/mathematik-ist-wie-dieses-bild/

What are ways to raise the priority of this bug?

(In reply to Rustam from comment #65) > What are ways to raise the priority of this bug? Focus on getting cairo updated, that's the best way.

Same on FF 19.0. Another example page: http://ruby.railstutorial.org/ruby-on-rails-tutorial-book Cause: background: url("/images/layout/book_bg.png") repeat-y scroll 0% 0% transparent; Note that this bug prevents sites that display their info (like a book chapter) in a single page (who doesn't hate those sites that divides a page into several shorter ones just to artificially increase their hit count?)

32768 = 2^15 Looks like it's just a case to replace a 'signed int16' to an 'unsigned int16'. But it's just a guess, I haven't checked the source code.

(In reply to Adriano P from comment #68) > 32768 = 2^15 > Looks like it's just a case to replace a 'signed int16' to an 'unsigned > int16'. But it's just a guess, anyone here to confirm this?

Even if it would be that easy, it would just increase the supported height to 2^16 = 65536. Who says, that would be enough?

(In reply to :aceman from comment #70) > Even if it would be that easy, it would just increase the supported height > to 2^16 = 65536. Who says, that would be enough? It´s just a starting point. If negative number are not required here, changing it from signed to unsigned might be easier to compile. But using a 32 or 64 bytes integer would indeed make more sense. (But, as I said, it's just a [poor] guess assuming the problem is only a matter of an integer variable; I only wondered by the coincidence of the 2^15.)

Well, backgrounds are not the only thing going wrong on large sites. The positioning of text (and other) content MAY be subject to wrong calculations at the 16-bit-integer-boundary, too. Of course, the effect MAY be caused by the background not erasing (and this keep being a background only problem). I have seen some artefacts in blogs like here (ignore the content for the moment and concentrate on the technical fact, please): http://www.planet-liebe.de/threads/große-umfrage-für-frauen-teil-1.21427/ Scroll to the bottom to see misplaced text overlays.

(In reply to White-Gandalf from comment #73) > I have seen some artefacts in blogs like here (ignore the content for the > moment and concentrate on the technical fact, please): > > http://www.planet-liebe.de/threads/große-umfrage-für-frauen-teil-1.21427/ This is most certainly caused by the background not erasing, as you said: try editing the site's CSS to disable the background image, and the other rendering errors disappear immediately as well.

Confirmed. Removing the background image with firebug leads to correct contents rendering. Thanks for the workaround tip.

<style> html { background: repeat scroll orange; background-image: /*from:www.grsites.com*/ url(http://static2.grsites.com/archive/textures/lgren/lgren006.jpg); } </style> <pre><center> <script> for( var i=1; i<=5000; i++ ) document.write("line "+i+"\n"); </script> </center></pre> ============ Somewhere near line 2000±500 of displayed page (the exact position is varying), browser stops showing background image and begins to display background color.

BTW, this problem does not occur when you set gfx.content.azure.enabled to false.

That's odd, because the issue is still present for me even with that option set to false, even after a browser restart. (on FF24.0)

Sometimes beyond the terminator line you may observe a sequence of interference stripes filled with relics of background image..

I have the same problem and have noted that the page I am dealing with is 37,259 pixels high. However, the problem does not show up in any browser but Firefox. I have version 24. It works fine in Internet Explorer 9 and 10, Safari 5.1.7, and in Chrome. The file also displays fine in Microsoft Expressions Web 4.

Maybe this is interesting, but in 25.0.1 it seems to be working fine, while on 25.0 the bug can be reproduced. Was this fixed deliberately?

That's odd, because the bug is still present for me in 25.0.1 (Hungarian version). On what page did you test this?

(In reply to tomasz.poreba from comment #82) > Maybe this is interesting, but in 25.0.1 it seems to be working fine, while > on 25.0 the bug can be reproduced. Was this fixed deliberately? With Firefox 64 bit, this bug does not exist.

(In reply to Steven Peter Papp from comment #83) > That's odd, because the bug is still present for me in 25.0.1 (Hungarian > version). On what page did you test this? I used attachment 545674 [details] from this bug. I also have same effect on my web application I am developing with repeating image in div about 65k px wide. Colleague of mine is still using FF 25.0 (same version, just before updating) and he can reproduce this in both cases, while for me the bug does not exist. (In reply to Zéfling from comment #84) > With Firefox 64 bit, this bug does not exist. It seems I am using 32 bit Firefox. I am on Windows 7, I see "firefox.exe *32" in task manager, as far as I know this indicates 32bit processes. My user agent shows "WOW64" - this also indicates 32bit emulation.

(In reply to Zéfling from comment #84) > With Firefox 64 bit, this bug does not exist. Comment 8 says: The reason this happens is because we pass in a src_y to pixman_image_composite32 that fails the IS_16BIT test in analyze_extents. This error seems to be related to the (limited) bit width of variables. As the range of integer variables doubles when compiling for 64 bit instead of 32 bit, maybe with Firefox 64 bit you also need the double page height for the error to appear.

Works for me in 25.0.1, no sign of bug. I didn't test in 25.0.0, though. BTW, maybe I'm wrong but in 64-bit build variables' range won't double, their bit width doubles, so their range is 2^32 instead of 2^16. In that case bug may appear at ~2147483648px, but I guess that's wontfix :)

Bug is still here, at least with Firefox 25.0.1 on Windows 8.1. I tried to capture a screenshot of Planet Mozilla but the output was cut at 32760px.

(In reply to Martin Vendl from comment #87) > BTW, maybe I'm wrong but in 64-bit build variables' range won't double, > their bit width doubles, so their range is 2^32 instead of 2^16. In that > case bug may appear at ~2147483648px, but I guess that's wontfix :) Oh sorry, you're completely right, Martin. Just one bit more would already double a variable's range of numbers. My Monitor has a vertical resolution of 1200px, that would be about 1789570 pages to scroll down. Pretty tough to test. ;-)

Please notice the limit here is 32768px, which it only 15bits (or a 16bit signed variable). So that is already less than 32bit int on a 32bit system so there is some other limit applied here. It is not sure compiling for 64bit does change this in any way.

Interestingly, when I reach the 32768px point in the above test page, the background above the limit gets messed up too. I reverts to normal only once the pixel limit is no longer in view.

Final release -- with autoscrolling and impressive visual effects..

Nobody yet spoken about repeating-linear-gradient? The same 32k bug, but the case isn't so interesting: Ffx just refuse to display specified background when page's height is over 32Kpx.

The same bug in X-dimension

Another observation: with zoom factor different from 1:1, background near 'terminator line' turns to black and page becomes unreadable.

I think I have a patch for this. Can somebody please test the build at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mstange@themasta.com-95ee48598e95/try-win32/ and tell me whether that fixes the problem?

(In reply to Markus Stange [:mstange] from comment #100) > I think I have a patch for this. Can somebody please test the build at > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mstange@themasta. > com-95ee48598e95/try-win32/ > and tell me whether that fixes the problem? I can confirm that Attachment 545674 [details], Attachment 8338647 [details] & Attachment 8413192 [details] are WFM using that Trybuild against the Cairo backend (e.g. using HWA/off).

Same here with your build and HWA disabled, 3 attachments work fine. Settings: DirectWrite Enabled false (6.2.9200.16571) AzureCanvasBackend skia AzureContentBackend cairo AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0

This patch got r+ from roc in bug 1011166.

Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0 Verified all testcases here are fixed in today's Nightly

guys, can you be quicker? Which Ff V will fix it?

(In reply to trespassersW from comment #109) > guys, can you be quicker? Which Ff V will fix it? See "Target Milestone" field: "mozilla33" means Firefox 33 Gradients aren't fixed, see bug 1011166 (changing summery)

This bug SEEMS fixed in FF 32 on my Win7 box, but only because HWA has suddenly begun to work (in previous releases HWA was disabled regardless of my choice). Since I've not changed my old graphics driver, I wonder: did anything change in FF 32 regarding HWA or blocked drivers? Is there a bug or thread on this?

Yes, there was a change, though we're about to back it out and re-release 32 with the old behaviour (due to bug 1062452), so you could be seeing that.

Assuming this makes it into FF33, how can I request/ask that it be included in the next ESR update as well?

> how can I request/ask that it be included in the next ESR update as well? ESR point releases are for security updates only.