User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0

Steps to reproduce:

Open the attached PDF in Firefox (tried 106.0.5 and 107.0b9, happens since early this year though IIRC)

Actual results:

The displayed content is wrong in many aspects, in this example both the letters "B" and "C" are displayed as "8", some letter blocks have wrong alignment, etc.
Changing the source and regenerating the PDF can result in slightly different problems (different letters affected, different alignment problems).

Expected results:

Correct display as for example in Acrobat Reader or Chrome.

The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

There is something wrong with:
https://github.com/mozilla/pdf.js/blob/f7449563ef8722df30c2988fe571236ab9eb89f9/src/core/operator_list.js#L155-L271
If I comment this block then there are no more wrong alignment.

There wrong "C" & "B" images above the horizontal line are something else (maybe a cache issue somewhere).

(In reply to Calixte Denizet (:calixte) from comment #2)

There is something wrong with:
https://github.com/mozilla/pdf.js/blob/f7449563ef8722df30c2988fe571236ab9eb89f9/src/core/operator_list.js#L155-L271
If I comment this block then there are no more wrong alignment.

That might be a red herring, since mozregression points to https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e3fb9f4b3db8772e54636c30426bbbd911deb8ad&tochange=7ec7dd0cc7acbd0941e8b97e126a62faaffbc20e
After that bisecting stopped, being unable to find a build, however bug 1720361 is the only PDF.js-related patch in there. Out of the listed PRs https://github.com/mozilla/pdf.js/pull/13683 looks the most suspicious, since it touches code related to OPS.paintImageMaskXObjectGroup and OPS.paintImageMaskXObjectRepeat.

There wrong "C" & "B" images above the horizontal line are something else (maybe a cache issue somewhere).

Yes, something seems to go wrong when caching in the Parser.makeInlineImage method. Unfortunately I don't immediately understand what though.

Set release status flags based on info from the regressing bug 1720361

(In reply to Jonas Jenwald [:Snuffleupagus] from comment #3)

(In reply to Calixte Denizet (:calixte) from comment #2)

There wrong "C" & "B" images above the horizontal line are something else (maybe a cache issue somewhere).

Yes, something seems to go wrong when caching in the Parser.makeInlineImage method. Unfortunately I don't immediately understand what though.

The culprit for this part of the bug is the computeAdler32 function, since it appears to generate hash collisions for some of the inline image data in question. While it's trivial to replace it with something better, e.g. our existing MurmurHash3_64 class, that'd affect performance quite badly in already slow cases (for example issue 2618).

My theory is that the computeAdler32 function doesn't cope well with very short data, which is the case here, so we could perhaps use MurmurHash3_64 for sufficiently "short" inline images. Although it's not clear to me where the cut-off point should be, to avoid performance regressions elsewhere?

Yep I think https://github.com/mozilla/pdf.js/pull/13683 is the culprit.
Especially:
https://github.com/mozilla/pdf.js/pull/13683/files#diff-76166cff75cae0ec9c490ae47aebbdadff02dbc1e26caaf93779a1bace64dc47R2475-R2487

Before the patch we set a transformation in the context and then draw the image which that the image drawing depends on the transformation.
After the patch, the point (top-left corner) where the image is drawn is correct, the image itself is transformed (mirrored, scaled, ...) but the bottom-right corner is likely wrong.

Set release status flags based on info from the regressing bug 1720361

Reproducible on a 2022-11-09 Nightly build on Windows 10.
Verified as fixed on Firefox 109.0b4(build ID: 20221218190303) and Nightly 110.0a1(build ID: 20221218193142) on Windows 10, macOS 12, Ubuntu 22.