967656 - Rendering image with dimension over 2¹⁵ - 1 will fail

Status: RESOLVED DUPLICATE of bug 591822

(Core :: Graphics: ImageLib, defect)

Description

[Simonas Kazlauskas [:nagisa/:simukis]]

Attachment: 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.

Comment 1

[Simonas Kazlauskas [:nagisa/:simukis]]

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.

Comment 2

[:Gijs (he/him)]

Missed the use of canvas.

Comment 3

[Simonas Kazlauskas [:nagisa/:simukis]]

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

Comment 4

[Glenn Randers-Pehrson]

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.

Comment 5

[Glenn Randers-Pehrson]

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.

Comment 6

[Glenn Randers-Pehrson]

(In reply to Glenn Randers-Pehrson from comment #4)
> Confirmed with nightly 2014-010-31

That should say "nightly 2014-01-31".

Comment 7

[Glenn Randers-Pehrson]

Firefox 26.0 is not affected.

Comment 8

[Glenn Randers-Pehrson]

Firefox 27.0, mozilla-release - changeset - 168007:b8896fee530d, is not affected.

Comment 9

[Glenn Randers-Pehrson]

Firefox 27.0b1 (hg revision 166721) displays the test image properly.  Firefox 27.0b2 (hg revision 166797) fails.

Comment 11

[Boris Zbarsky [:bzbarsky]]

On Mac I see identical rendering in Firefox 27, Firefox 26, and Firefox 20: two bubbles.

Comment 12

[Glenn Randers-Pehrson]

I've found the regression bug.  It's locked so I won't reference it here, and I can't look at it myself.

Comment 13

[Stephen A Pohl [:spohl]]

Glenn, could you run mozregression[1] to confirm the regression range on m-c? Please feel free to ping me on IRC if you'd like.

[1] http://mozilla.github.io/mozregression/

Comment 14

[Glenn Randers-Pehrson]

No, I cannot, because of bug #943247.  Every build I attempt in that time frame fails because of the problem described there.

Comment 15

[Glenn Randers-Pehrson]

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.

Comment 16

[Glenn Randers-Pehrson]

Attachment: 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.

Comment 17

[Glenn Randers-Pehrson]

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?

Comment 18

[Glenn Randers-Pehrson]

Chrome displays all four images on the new test page properly, as it did with the original test page (see comment # 3).

Comment 19

[Simonas Kazlauskas [:nagisa/:simukis]]

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.

Comment 20

[Kelsey Gilbert [:jgilbert]]

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

Comment 21

[Glenn Randers-Pehrson]

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.

Comment 22

[Glenn Randers-Pehrson]

I believe that this is a dupe of bug #591822, which is still NEW.

Comment 23

[[:Aleksej]]

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