Last Comment Bug 671302 - (pixman-coord) cairo-gdi: large background-images don't work beyond ~ 32768px
(pixman-coord)
: cairo-gdi: large background-images don't work beyond ~ 32768px
Status: VERIFIED FIXED
: regression, testcase
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All All
: P3 normal with 36 votes (vote)
: mozilla33
Assigned To: Jeff Muizelaar [:jrmuizel]
:
:
Mentors:
: 677174 685174 690789 692350 693965 699808 702906 706296 727305 732550 745110 747767 747829 769228 773674 784853 812984 839851 858395 867022 995129 1016915 1030538 1065364 (view as bug list)
Depends on: 739096 678505
Blocks: 562746
  Show dependency treegraph
 
Reported: 2011-07-13 09:23 PDT by tpv
Modified: 2015-03-15 04:29 PDT (History)
72 users (show)
ryanvm: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
-
-
-
affected
affected
affected
affected
affected
affected
affected
affected
affected
verified
-
-


Attachments
temp.html (486 bytes, text/html)
2011-07-13 09:23 PDT, tpv
no flags Details
show case (4.02 KB, text/html)
2013-11-24 07:12 PST, trespassersW
no flags Details
testsuit (4.70 KB, text/html)
2013-11-25 01:14 PST, trespassersW
no flags Details
bz671302.htm (5.18 KB, text/html)
2013-11-25 05:52 PST, trespassersW
no flags Details
test suit (7.06 KB, text/html)
2013-11-26 10:12 PST, trespassersW
no flags Details
32k in horizontal direction (8.03 KB, text/html)
2014-04-26 07:10 PDT, trespassersW
no flags Details
patch, r=roc (9.71 KB, patch)
2014-07-18 02:49 PDT, Markus Stange [:mstange]
no flags Details | Diff | Splinter Review

Description tpv 2011-07-13 09:23:39 PDT
Created attachment 545674 [details]
temp.html

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
Comment 1 Alice0775 White 2011-07-13 11:32:38 PDT
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
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2011-07-14 10:36:59 PDT
This seems like a correctness regression we should track for 7 and 8....
Comment 3 Jeff Muizelaar [:jrmuizel] 2011-08-12 12:35:48 PDT
This only seems to impact cairo-gdi
Comment 4 Jeff Muizelaar [:jrmuizel] 2011-08-16 12:10:11 PDT
(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?
Comment 5 Jeff Muizelaar [:jrmuizel] 2011-08-18 13:08:02 PDT
I can't reproduce this on FF9 anymore :( It would be good to get a regression window on the thing that fixed it.
Comment 6 Alice0775 White 2011-08-18 13:30:25 PDT
(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
Comment 7 Jeff Muizelaar [:jrmuizel] 2011-08-18 13:59:41 PDT
Yes, even with HWA disabled I still can't reproduce this any more.
Comment 8 Jeff Muizelaar [:jrmuizel] 2011-08-18 14:47:00 PDT
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.
Comment 9 Jeff Muizelaar [:jrmuizel] 2011-08-19 08:56:23 PDT
This problem exists on older versions of FF it's just rarer.
Comment 10 christian 2011-09-15 13:35:16 PDT
Jeff, is this something we need to worry about for Firefox 7? I doubt it but would like your opinion.
Comment 11 :aceman 2011-10-03 04:57:19 PDT
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.
Comment 12 thepiglovesyou 2011-10-12 06:06:48 PDT
*** Bug 693965 has been marked as a duplicate of this bug. ***
Comment 13 j.j. 2011-11-04 09:47:46 PDT
*** Bug 699808 has been marked as a duplicate of this bug. ***
Comment 14 j.j. 2011-11-04 09:48:36 PDT
*** Bug 685174 has been marked as a duplicate of this bug. ***
Comment 15 j.j. 2011-11-04 09:49:26 PDT
*** Bug 690789 has been marked as a duplicate of this bug. ***
Comment 16 nbz 2011-11-07 07:53:15 PST
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 ).
Comment 17 j.j. 2011-11-07 09:44:06 PST
*** Bug 672726 has been marked as a duplicate of this bug. ***
Comment 18 j.j. 2011-11-07 09:44:15 PST
*** Bug 683681 has been marked as a duplicate of this bug. ***
Comment 19 j.j. 2011-11-07 09:44:27 PST
*** Bug 677174 has been marked as a duplicate of this bug. ***
Comment 20 j.j. 2011-11-07 09:58:38 PST
This makes pages with dark background-image and light text partly unreadable, e.g.
http://armageddonconspiracy.co.uk/
Comment 21 ahuelsbergen 2011-11-14 06:53:06 PST
background image issue no longer visible on firefox 8 for mac (OS Lion 10.7.2)
Comment 22 j.j. 2011-11-16 07:07:19 PST
*** Bug 702906 has been marked as a duplicate of this bug. ***
Comment 23 Otshelnik 2011-11-16 08:59:22 PST
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
Comment 24 Sid 2011-11-16 09:19:32 PST
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.
Comment 25 Andrew 2011-11-16 10:09:27 PST
Does not work at all the sides, not only down (in userChrome/userContent too).
Comment 26 Otshelnik 2011-11-17 00:09:53 PST
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
Comment 27 Alex Keybl [:akeybl] 2011-11-28 13:20:03 PST
[Triage Comment]
Is there any reason to believe that this will occur with any greater frequency in FF9/10 than in FF8?
Comment 28 j.j. 2011-11-29 14:50:44 PST
No
Comment 29 Alex Keybl [:akeybl] 2011-11-29 15:33:24 PST
(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.
Comment 30 Grigory 2011-12-27 23:10:53 PST
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.
Comment 31 Mardeg 2011-12-27 23:21:53 PST
*** Bug 692350 has been marked as a duplicate of this bug. ***
Comment 32 jidewe 2012-01-19 06:50:50 PST
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.
Comment 33 Kartikaya Gupta (email:kats@mozilla.com) 2012-01-26 09:55:12 PST
*** Bug 706296 has been marked as a duplicate of this bug. ***
Comment 34 Kartikaya Gupta (email:kats@mozilla.com) 2012-01-26 09:57:28 PST
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?
Comment 35 Kartikaya Gupta (email:kats@mozilla.com) 2012-01-31 08:09:23 PST
Requesting tracking-fennec as per IRC discussion with mfinkle; this affects fennec as well.
Comment 36 Tim (fmdeveloper) 2012-02-15 14:45:01 PST
*** Bug 727305 has been marked as a duplicate of this bug. ***
Comment 37 Tim (fmdeveloper) 2012-03-02 16:21:55 PST
*** Bug 732550 has been marked as a duplicate of this bug. ***
Comment 38 Max Scherban 2012-03-05 15:13:44 PST
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
Comment 39 zev 2012-03-11 18:26:15 PDT
(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.
Comment 40 zev 2012-03-11 18:33:01 PDT
(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
Comment 41 zev 2012-03-11 18:52:37 PDT
(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
Comment 42 Michael Hohner 2012-03-15 00:47:25 PDT
occurs in Firefox 11.
Comment 43 sane 2012-04-03 17:16:50 PDT
occurs in Firefox 12 beta.
Comment 44 Timothy Nikkel (:tnikkel) 2012-04-03 17:22:57 PDT
We don't need any further updates on this not being fixed, this bug is still open indicating that it is not fixed.
Comment 45 Mardeg 2012-04-13 01:23:42 PDT
*** Bug 745110 has been marked as a duplicate of this bug. ***
Comment 46 Matthias Versen [:Matti] 2012-04-22 14:15:54 PDT
*** Bug 747767 has been marked as a duplicate of this bug. ***
Comment 47 Mardeg 2012-04-22 22:30:15 PDT
*** Bug 747829 has been marked as a duplicate of this bug. ***
Comment 48 Kartikaya Gupta (email:kats@mozilla.com) 2012-05-08 07:20:53 PDT
*** Bug 752799 has been marked as a duplicate of this bug. ***
Comment 49 Kartikaya Gupta (email:kats@mozilla.com) 2012-05-08 07:22:14 PDT
Nom'ing as fennec blocker. It affects a number of long pages in fennec.
Comment 50 :aceman 2012-05-08 07:40:50 PDT
What about cairo 1.12?
Comment 51 Joe Drew (not getting mail) 2012-05-08 12:36:37 PDT
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.
Comment 52 rcouture 2012-06-27 08:20:28 PDT
Occurs in Firefox 13.  https://www.allegromicro.com/en/Sample-And-Buy/Contact-Sales.aspx
Comment 53 RNicoletto 2012-06-27 11:37:25 PDT
(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).
Comment 54 Loic 2012-06-28 07:51:02 PDT
*** Bug 769228 has been marked as a duplicate of this bug. ***
Comment 55 Loic 2012-07-13 14:13:27 PDT
*** Bug 773674 has been marked as a duplicate of this bug. ***
Comment 56 [:Aleksej] 2012-08-24 08:46:42 PDT
*** Bug 784853 has been marked as a duplicate of this bug. ***
Comment 57 Pink Ink 2012-09-20 01:50:28 PDT
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/).
Comment 58 Matthias Versen [:Matti] 2012-11-19 09:15:14 PST
*** Bug 812984 has been marked as a duplicate of this bug. ***
Comment 59 Alice0775 White 2012-11-30 02:42:28 PST
*** Bug 816917 has been marked as a duplicate of this bug. ***
Comment 60 Miroslav Milev 2012-11-30 03:06:18 PST
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?
Comment 61 Alice0775 White 2012-11-30 08:49:00 PST
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.
Comment 62 Loic 2012-11-30 08:57:32 PST
Maybe updating to cairo 1.12.8 will fix it (bug 739096).
Comment 63 White-Gandalf 2013-02-04 17:13:40 PST
Still in Firefox 18.

Example page: http://halbtagsblog.de/schule/mathematik-ist-wie-dieses-bild/
Comment 64 Mardeg 2013-02-10 19:30:08 PST
*** Bug 839851 has been marked as a duplicate of this bug. ***
Comment 65 Rustam 2013-02-10 19:49:48 PST
What are ways to raise the priority of this bug?
Comment 66 randyzie 2013-02-12 16:16:13 PST
(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.
Comment 67 Adriano P 2013-02-24 15:09:42 PST
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?)
Comment 68 Adriano P 2013-02-24 15:18:41 PST
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.
Comment 69 j.j. 2013-02-24 17:05:54 PST
(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?
Comment 70 :aceman 2013-02-24 17:17:28 PST
Even if it would be that easy, it would just increase the supported height to 2^16 = 65536. Who says, that would be enough?
Comment 71 Adriano P 2013-02-24 17:28:45 PST
(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.)
Comment 72 Loic 2013-04-05 10:00:18 PDT
*** Bug 858395 has been marked as a duplicate of this bug. ***
Comment 73 White-Gandalf 2013-04-06 10:48:23 PDT
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.
Comment 74 Mardeg 2013-04-29 19:13:42 PDT
*** Bug 867022 has been marked as a duplicate of this bug. ***
Comment 75 Steven Peter Papp 2013-06-06 07:56:26 PDT
(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.
Comment 76 White-Gandalf 2013-06-06 13:58:05 PDT
Confirmed. Removing the background image with firebug leads to correct contents rendering. Thanks for the workaround tip.
Comment 77 trespassersW 2013-10-02 09:32:26 PDT
<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.
Comment 78 Michael Hohner 2013-10-02 13:07:51 PDT
BTW, this problem does not occur when you set gfx.content.azure.enabled to false.
Comment 79 Steven Peter Papp 2013-10-02 15:22:19 PDT
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)
Comment 80 trespassersW 2013-10-03 02:38:52 PDT
Sometimes beyond the terminator line you may observe a sequence of interference stripes filled with relics of background image..
Comment 81 Mike Sutherland 2013-10-27 06:38:54 PDT
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.
Comment 82 tomasz.poreba 2013-11-20 07:21:52 PST
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?
Comment 83 Steven Peter Papp 2013-11-20 07:26:43 PST
That's odd, because the bug is still present for me in 25.0.1 (Hungarian version). On what page did you test this?
Comment 84 Zéfling 2013-11-20 07:43:08 PST
(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.
Comment 85 tomasz.poreba 2013-11-20 09:11:13 PST
(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.
Comment 86 Pink Ink 2013-11-21 02:37:44 PST
(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.
Comment 87 Martin Vendl 2013-11-21 07:45:34 PST
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 :)
Comment 88 RNicoletto 2013-11-21 12:31:50 PST
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.
Comment 89 Pink Ink 2013-11-22 05:04:39 PST
(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. ;-)
Comment 90 :aceman 2013-11-22 05:25:42 PST
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.
Comment 91 trespassersW 2013-11-24 07:12:36 PST
Created attachment 8337383 [details]
show case
Comment 92 Steven Peter Papp 2013-11-24 14:17:07 PST
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.
Comment 93 trespassersW 2013-11-25 01:14:48 PST
Created attachment 8337615 [details]
testsuit
Comment 94 trespassersW 2013-11-25 05:52:31 PST
Created attachment 8337718 [details]
bz671302.htm
Comment 95 trespassersW 2013-11-26 10:12:31 PST
Created attachment 8338647 [details]
test suit


 Final release -- with autoscrolling and impressive visual effects..
Comment 96 trespassersW 2013-12-15 12:42:46 PST
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.
Comment 97 Kartikaya Gupta (email:kats@mozilla.com) 2014-04-25 10:31:57 PDT
*** Bug 995129 has been marked as a duplicate of this bug. ***
Comment 98 trespassersW 2014-04-26 07:10:48 PDT
Created attachment 8413192 [details]
32k in horizontal direction

The same bug in X-dimension
Comment 99 trespassersW 2014-04-27 00:24:22 PDT
Another observation: with zoom factor different from 1:1, background near 'terminator line' turns to black and page becomes unreadable.
Comment 100 Markus Stange [:mstange] 2014-05-19 09:27:29 PDT
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?
Comment 101 (mostly gone) XtC4UaLL [:xtc4uall] 2014-05-19 10:56:37 PDT
(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).
Comment 102 Loic 2014-05-19 13:29:37 PDT
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
Comment 103 Nicolas Silva [:nical] 2014-06-18 08:19:14 PDT
*** Bug 1016915 has been marked as a duplicate of this bug. ***
Comment 104 Milan Sreckovic [:milan] 2014-06-26 08:17:42 PDT
*** Bug 1030538 has been marked as a duplicate of this bug. ***
Comment 105 Markus Stange [:mstange] 2014-07-18 02:49:03 PDT
Created attachment 8458564 [details] [diff] [review]
patch, r=roc

This patch got r+ from roc in bug 1011166.
Comment 107 Ryan VanderMeulen [:RyanVM] 2014-07-18 12:09:04 PDT
https://hg.mozilla.org/mozilla-central/rev/0a865eaa597c
Comment 108 j.j. 2014-07-20 08:06:19 PDT
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
Comment 109 trespassersW 2014-08-08 04:22:53 PDT
guys, can you be quicker? Which Ff V will fix it?
Comment 110 trespassersW 2014-08-08 04:40:14 PDT Comment hidden (spam)
Comment 111 j.j. 2014-08-08 09:15:28 PDT
(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)
Comment 112 Loic 2014-09-10 10:11:58 PDT
*** Bug 1065364 has been marked as a duplicate of this bug. ***
Comment 113 Loic 2014-09-10 11:04:44 PDT
*** Bug 1065364 has been marked as a duplicate of this bug. ***
Comment 114 Francesco 2014-09-11 09:17:28 PDT
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?
Comment 115 Milan Sreckovic [:milan] 2014-09-11 10:33:48 PDT
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.
Comment 116 joelb 2014-09-19 14:49:26 PDT
Assuming this makes it into FF33, how can I request/ask that it be included in the next ESR update as well?
Comment 117 j.j. 2014-09-19 18:51:04 PDT
> how can I request/ask that it be included in the next ESR update as well?

ESR point releases are for security updates only.

Note You need to log in before you can comment on or make changes to this bug.