1798532 - panoramic picture does not display properly

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect, P2)

Description

[Warren Dodge]

Attachment: Screenshot from 2022-11-01 10-01-41.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0

Steps to reproduce:

start firefox
got to this url
http://rzr.wdx.mybluehost.me/bugzilla/20180621_151932_BAD.jpg
also fails if you have file local and do
firefox 20180621_151932_BAD.jpg

This url is the same file opened by gimp and exported as a new jpg which works. This just changed things in the attributes of the picture not the image.

http://rzr.wdx.mybluehost.me/bugzilla/20180621_151932_WORKS.jpg

Actual results:

instead of displaying the picture displays as the url instead as seen in attached screenshot

Expected results:

picture should have displayed

The picture ware taken in 2018-06-21 with a galaxy S7 SM-G930V

Comment 1

[Alice0775 White]

Error in Browser console:

Image corrupt or truncated.

Comment 2

[Timothy Nikkel (:tnikkel)]

In a debug build Firefox outputs
JPEG decoding error:
Unsupported marker type 0xb6

So we probably just need to ignore unknown marker types.

Comment 3

[Brad Werth [:bradwerth]]

I'll try to fix this.

Comment 4

[Brad Werth [:bradwerth]]

Bug 1787515 should possibly be a blocker. For now, I'll look for a config option that can get us past these unknown markers.

Comment 5

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #4)

Bug 1787515 should possibly be a blocker. For now, I'll look for a config option that can get us past these unknown markers.

From looking at the error trigger in read_markers, it's clear that version 2.1.4 of libjpeg-turbo would not change how this error is handled.

Comment 6

[Brad Werth [:bradwerth]]

Attachment: Bug 1798532 Part 1: Ignore JPEG unknown markers.

This will push through any unknown marker errors from libjpeg, but still
fail for other errors. An unknown marker at the end is a special case that
returns success. This prevents an infinite loop in completing the JPEG
processing.

Comment 7

[Brad Werth [:bradwerth]]

I'd like to get a simpler testcase that isn't a 45mb file, to put in the tree as an automated test. Can you generate one using the same method you used to generate the panorama?

Comment 8

[Warren Dodge]

Here is a smaller file of 29577459

rzr.wdx.mybluehost.me/bugzilla/20180618_141440_SMALL_BAD.jpg

I no long have that phone so need to use existing photos

Comment 9

[Timothy Nikkel (:tnikkel)]

The jpeg format is pretty simple: https://en.wikipedia.org/wiki/JPEG#Syntax_and_structure

It shouldn't be too hard to add 0xb6 marker to a small valid jpeg using a hex editor, possibly looking at the existing badfile to copy the bad marker.

It would be good to include both a jpeg with the invalid marker at the end, and one with the marker in the middle or earlier to make sure the non-terminate branch is taken and work correctly.

Thanks!

Comment 10

[Brad Werth [:bradwerth]]

Attachment: Bug 1798532 Part 2: Test display of a JPEG with 0xb6 markers.

This has been edited to add one 0xb6 marker after the header, and one
after the end of image marker.

Depends on D161187

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/580f2ee8df44
Part 1: Ignore JPEG unknown markers. r=tnikkel
https://hg.mozilla.org/integration/autoland/rev/c07e03c68b6c
Part 2: Test display of a JPEG with 0xb6 markers. r=tnikkel

Comment 12

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/580f2ee8df44
https://hg.mozilla.org/mozilla-central/rev/c07e03c68b6c

Comment 13

[Alice0775 White]

On Windows 10, the comment#0 image (http://rzr.wdx.mybluehost.me/bugzilla/20180621_151932_BAD.jpg) is not displayed in the autoland build (c07e03c68b6c). Is this an expected result?

Comment 14

[Brad Werth [:bradwerth]]

(In reply to Alice0775 White from comment #13)

On Windows 10, the comment#0 image (http://rzr.wdx.mybluehost.me/bugzilla/20180621_151932_BAD.jpg) is not displayed in the autoland build (c07e03c68b6c). Is this an expected result?

No, this is unexpected. I'll re-open the Bug while I fix this.

Comment 15

[Brad Werth [:bradwerth]]

Attachment: Bug 1798532 Part 3: Allow JPEGDecoder to handle frame data in the footer.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f3f4ef6894dc
Part 3: Allow JPEGDecoder to handle frame data in the footer. r=tnikkel

Comment 17

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/f3f4ef6894dc

Comment 18

[Ardelean Oana, Desktop QA [:oardelean]]

Reproducible on a 2022-11-01 Nightly build on macOS 12 using the STR and links from Comment 0.
Verified as fixed on Firefox 108.0b4(build ID: 20221120185746) and Nightly 109.0a1(build ID: 20221120214001) on macOS 12 , Windows 10, Ubuntu 22.