Created attachment 8370176 [details] Minimal test case Try making firefox render whole or part of PNG image with any dimension (either width or height) over 2¹⁵-1 pixels. Image rendering will fail. Additional note: For failing image onload event does sometimes fire and sometimes doesn’t but image is broken regardless. See a small test case I attached.
By the way, in the minimal test case the image `w_ok` is 32767 pixels wide and 10 pixels tall, while image `w_bad` is one pixel wider. Both generated by GIMP.
Missed the use of canvas.
Component: ImageLib → Canvas: 2D
(In reply to :Gijs Kruitbosch from comment #2) > Missed the use of canvas. I’d leave component set to ImageLib. I used canvas to demonstrate that image is not decoded at all, not just the fact image can’t be shown. Clarifications to original report: 1) For the test case expected result is 4 blurred bubbles aligned in a vertical line. 2) I asked people on twitter to open the test case with different browsers and got following results: * Chrome(-ium), both mobile and desktop: 4 bubbles, as expected; * IE 11, Windows Phone 8 IE: 4 bubbles; * iPad/iPhone Safari: 4 bubbles; * Firefox varies between 0 and 2 bubbles.
Component: Canvas: 2D → ImageLib
Confirmed with nightly 2014-010-31 using embedded libpng and with a build from the tip of the mercurial repo using the system libpng. The "w_ok" and "w_bad" filenames seem to be swapped (the "ok" is 1 column wider than the "bad" one). I observe the same behavior if I convert them to BMP, so it doesn't seem to be specifically a PNG problem. Changing "PNG" to "image" in the bug title.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Rendering PNG with dimension over 2¹⁵ - 1 will fail → Rendering image with dimension over 2¹⁵ - 1 will fail
Clarifying: I had decoded the w_ok.png and w_bad.png manually from the base64 encoding and then tried to read them with the browser, so I'm not seeing any bubbles, just a narrow horizontal line across the middle of the screen for the "w_bad" ones and a broken image icon for the "w_ok" ones.
(In reply to Glenn Randers-Pehrson from comment #4) > Confirmed with nightly 2014-010-31 That should say "nightly 2014-01-31".
Firefox 26.0 is not affected.
Firefox 27.0, mozilla-release - changeset - 168007:b8896fee530d, is not affected.
Firefox 27.0b1 (hg revision 166721) displays the test image properly. Firefox 27.0b2 (hg revision 166797) fails.
Assignee: nobody → glennrp+bmo
On Mac I see identical rendering in Firefox 27, Firefox 26, and Firefox 20: two bubbles.
I've found the regression bug. It's locked so I won't reference it here, and I can't look at it myself.
Glenn, could you run mozregression to confirm the regression range on m-c? Please feel free to ping me on IRC if you'd like.  http://mozilla.github.io/mozregression/
No, I cannot, because of bug #943247. Every build I attempt in that time frame fails because of the problem described there.
OK, I am building OK on a laptop running Ubuntu 12.04LTS. Working on bisection now. It seems that the "minimal test case" attached above is failing sooner than simply viewing the images independently.
Created attachment 8393518 [details] Test both wide and tall images, 32767 vs 32768. Tests both wide and tall (32767 and 32768) PNG images, displayed on an easy-to-understand page.
Attachment #8370176 - Attachment is obsolete: true
I was misunderstanding what I was seeing with the original test case. With the new test case, I can see that no version going back as far as 14 months (hg revision 120000), displays the 32768 wide or tall image. The 32767 wide and tall images are shown properly at least as far back as revision 140000, but revision 120000 flashes them on screen and then they disappear. Is this a WONTFIX, then?
Chrome displays all four images on the new test page properly, as it did with the original test page (see comment # 3).
Safari (5.1, 5.0.5, both on windows), Opera (next, 19.0, 10.0, also on windows) and IE 9 all display the test case as expected too as tested via browserling. I’m not sure about marking it as WONTFIX as we still want to render images over 32767 pixels wide/tall, even if it is proved this bug is not a regression.
We limit to USHORT_MAX here: https://mxr.mozilla.org/mozilla-central/source/image/src/imgFrame.cpp#85 Further down in the function, we also limit to SHORT_MAX for mac. But what we're hitting here is something else: https://mxr.mozilla.org/mozilla-central/source/gfx/cairo/cairo/src/cairo-image-surface.c#94 It turns out Cairo doesn't want to handle anything larger than SHORT_MAX. This was added in the Cairo update from April 2010: https://hg.mozilla.org/mozilla-central/rev/f236632a9747
I knew that we used to be able to display big images, when we put in the limit of 1million x 1million in the PNG decoder after some debate. See comment in nsPNGDecoder.cpp: /* limit image dimensions (bug #251381) */ #define MOZ_PNG_MAX_DIMENSION 1000000L I hadn't noticed the change until I saw this bug recently. I'll change the MOZ_PNG_MAX_DIMENSION in the png decoder so we don't bother decoding a large image that we're going to throw away later.
I believe that this is a dupe of bug #591822, which is still NEW.
green-green: 2010-04-26-03-mozilla-central-firefox-3.7a5pre.en-US.linux-x86_64 green-none: 2010-04-27-03-mozilla-central-firefox-3.7a5pre.en-US.linux-x86_64
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 591822
4 years ago
Keywords: regression, regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.