Bug 671302 (pixman-coord)

cairo-gdi: large background-images don't work beyond ~ 32768px

VERIFIED FIXED in Firefox 33

Status

()

Core
Graphics
P3
normal
VERIFIED FIXED
6 years ago
2 years ago

People

(Reporter: tpv, Assigned: jrmuizel)

Tracking

(Depends on: 1 bug, {regression, testcase})

Trunk
mozilla33
regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox7+, firefox8-, firefox9-, firefox10-, firefox22 affected, firefox23 affected, firefox24 affected, firefox25 affected, firefox26 affected, firefox27 affected, firefox30 affected, firefox31 affected, firefox32 affected, firefox33 verified, blocking-fennec1.0 -, fennec-)

Details

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

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

Updated

6 years ago
OS: Other → Windows Vista
Attachment #545674 - Attachment mime type: text/plain → text/html

Comment 1

6 years ago
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
Blocks: 562746
Status: UNCONFIRMED → NEW
Component: General → Graphics
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → thebes

Updated

6 years ago
Keywords: regression
Assignee: nobody → jmuizelaar
This seems like a correctness regression we should track for 7 and 8....
tracking-firefox7: --- → ?
tracking-firefox8: --- → ?

Updated

6 years ago
tracking-firefox7: ? → +
tracking-firefox8: ? → ---
(Assignee)

Updated

6 years ago
Depends on: 678505
(Assignee)

Comment 3

6 years ago
This only seems to impact cairo-gdi
Summary: Background-images does not work on large divs → cairo-gdi: Background-images does not work on large divs
(Assignee)

Comment 4

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

Comment 5

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

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

Comment 7

6 years ago
Yes, even with HWA disabled I still can't reproduce this any more.
(Assignee)

Comment 8

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

Comment 9

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

Comment 10

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

Comment 11

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

Updated

6 years ago
Blocks: 685174

Updated

6 years ago
Blocks: 690789

Updated

6 years ago
Duplicate of this bug: 693965

Updated

6 years ago
Duplicate of this bug: 699808

Updated

6 years ago
Duplicate of this bug: 685174

Updated

6 years ago
Duplicate of this bug: 690789

Updated

6 years ago
tracking-firefox10: --- → ?
tracking-firefox8: --- → ?
tracking-firefox9: --- → ?

Comment 16

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

Updated

6 years ago
Duplicate of this bug: 672726

Updated

6 years ago
Duplicate of this bug: 683681

Updated

6 years ago
Duplicate of this bug: 677174

Updated

6 years ago
Summary: cairo-gdi: Background-images does not work on large divs → cairo-gdi: large background-images and gradients don't work beyond ~ 32735px
Version: 8 Branch → Trunk

Comment 20

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

Comment 21

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

Updated

6 years ago
Duplicate of this bug: 702906

Comment 23

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

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

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

Comment 26

6 years ago
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?
tracking-firefox8: ? → -

Comment 28

6 years ago
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.
tracking-firefox10: ? → -
tracking-firefox9: ? → -

Comment 30

5 years ago
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.

Updated

5 years ago
Duplicate of this bug: 692350

Comment 32

5 years ago
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.
Duplicate of this bug: 706296
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.
tracking-fennec: --- → ?
tracking-fennec: ? → 11+
Priority: -- → P3

Updated

5 years ago
Duplicate of this bug: 727305

Updated

5 years ago
Duplicate of this bug: 732550

Comment 38

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

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

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

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

5 years ago
occurs in Firefox 11.

Comment 43

5 years ago
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.

Updated

5 years ago
Duplicate of this bug: 745110
Duplicate of this bug: 747767

Updated

5 years ago
Duplicate of this bug: 747829
Duplicate of this bug: 752799
Nom'ing as fennec blocker. It affects a number of long pages in fennec.
blocking-fennec1.0: --- → ?

Comment 50

5 years ago
What about cairo 1.12?
blocking-fennec1.0: ? → -
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.
tracking-fennec: 11+ → -

Comment 52

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

Comment 53

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

Updated

5 years ago
Duplicate of this bug: 769228

Updated

5 years ago
Duplicate of this bug: 773674

Updated

5 years ago
Duplicate of this bug: 784853

Comment 57

5 years ago
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/).
Duplicate of this bug: 812984

Updated

5 years ago
Duplicate of this bug: 816917

Comment 60

5 years ago
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?

Updated

5 years ago
No longer blocks: 685174, 690789
OS: Windows Vista → All
Summary: cairo-gdi: large background-images and gradients don't work beyond ~ 32735px → cairo-gdi: large background-images and gradients don't work beyond ~ 32768px

Comment 61

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

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

Updated

5 years ago
Depends on: 739096

Comment 63

4 years ago
Still in Firefox 18.

Example page: http://halbtagsblog.de/schule/mathematik-ist-wie-dieses-bild/

Updated

4 years ago
Duplicate of this bug: 839851

Comment 65

4 years ago
What are ways to raise the priority of this bug?

Comment 66

4 years ago
(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

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

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

4 years ago
(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

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

4 years ago
(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.)

Updated

4 years ago
Duplicate of this bug: 858395

Comment 73

4 years ago
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.

Updated

4 years ago
Duplicate of this bug: 867022

Comment 75

4 years ago
(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

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

Updated

4 years ago
status-firefox22: --- → affected
status-firefox23: --- → affected
status-firefox24: --- → affected
status-firefox25: --- → affected
status-firefox-esr17: --- → affected

Comment 77

4 years ago
<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.

Updated

4 years ago
status-firefox26: --- → affected
status-firefox27: --- → affected
Keywords: testcase

Comment 78

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

Comment 79

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

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

Comment 81

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

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

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

4 years ago
(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

4 years ago
(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

4 years ago
(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

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

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

4 years ago
(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

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

4 years ago
Created attachment 8337383 [details]
show case

Comment 92

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

4 years ago
Created attachment 8337615 [details]
testsuit
Attachment #8337383 - Attachment is obsolete: true

Comment 94

4 years ago
Created attachment 8337718 [details]
bz671302.htm
Attachment #8337615 - Attachment is obsolete: true

Comment 95

4 years ago
Created attachment 8338647 [details]
test suit


 Final release -- with autoscrolling and impressive visual effects..
Attachment #8337718 - Attachment is obsolete: true

Comment 96

3 years ago
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.
See Also: → bug 995129
See Also: bug 995129
Duplicate of this bug: 995129

Comment 98

3 years ago
Created attachment 8413192 [details]
32k in horizontal direction

The same bug in X-dimension

Comment 99

3 years ago
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).

Comment 102

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

Updated

3 years ago
Duplicate of this bug: 1016915
(Assignee)

Updated

3 years ago
Alias: pixman-coord
Duplicate of this bug: 1030538
Created attachment 8458564 [details] [diff] [review]
patch, r=roc

This patch got r+ from roc in bug 1011166.
https://hg.mozilla.org/integration/mozilla-inbound/rev/0a865eaa597c
https://hg.mozilla.org/mozilla-central/rev/0a865eaa597c
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla33

Comment 108

3 years ago
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
Status: RESOLVED → VERIFIED
status-firefox30: --- → affected
status-firefox31: --- → affected
status-firefox32: --- → affected
status-firefox33: --- → verified
status-firefox-esr17: affected → ---

Comment 109

3 years ago
guys, can you be quicker? Which Ff V will fix it?
Comment hidden (spam)

Comment 111

3 years ago
(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)
Summary: cairo-gdi: large background-images and gradients don't work beyond ~ 32768px → cairo-gdi: large background-images don't work beyond ~ 32768px

Updated

3 years ago
Duplicate of this bug: 1065364

Updated

3 years ago
Duplicate of this bug: 1065364

Comment 114

3 years ago
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.

Comment 116

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

Comment 117

3 years ago
> how can I request/ask that it be included in the next ESR update as well?

ESR point releases are for security updates only.
See Also: → bug 1143312
You need to log in before you can comment on or make changes to this bug.