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

RESOLVED DUPLICATE of bug 591822

Status

()

Core
ImageLib
RESOLVED DUPLICATE of bug 591822
4 years ago
4 years ago

People

(Reporter: nagisa, Assigned: Glenn Randers-Pehrson)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

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

Updated

4 years ago
Component: General → ImageLib
Product: Firefox → Core

Comment 2

4 years ago
Missed the use of canvas.
Component: ImageLib → Canvas: 2D
(Reporter)

Comment 3

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

Comment 4

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

Comment 5

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

Comment 6

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

That should say "nightly 2014-01-31".
(Assignee)

Comment 7

4 years ago
Firefox 26.0 is not affected.
(Assignee)

Comment 8

4 years ago
Firefox 27.0, mozilla-release - changeset - 168007:b8896fee530d, is not affected.
(Assignee)

Comment 9

4 years ago
Firefox 27.0b1 (hg revision 166721) displays the test image properly.  Firefox 27.0b2 (hg revision 166797) fails.
Keywords: regression
(Assignee)

Updated

4 years ago
Duplicate of this bug: 978893
(Assignee)

Updated

4 years ago
Assignee: nobody → glennrp+bmo
Keywords: regressionwindow-wanted
On Mac I see identical rendering in Firefox 27, Firefox 26, and Firefox 20: two bubbles.
(Assignee)

Comment 12

4 years ago
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[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/
(Assignee)

Comment 14

4 years ago
No, I cannot, because of bug #943247.  Every build I attempt in that time frame fails because of the problem described there.
(Assignee)

Comment 15

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

Comment 16

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

Updated

4 years ago
Attachment #8370176 - Attachment is obsolete: true
(Assignee)

Comment 17

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

Comment 18

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

Comment 19

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

Comment 21

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

Comment 22

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

Comment 23

4 years ago
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
Keywords: regression, regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.