fix(previews): Stop returning true when getimagesize() fails

[joshtrichards]

• Resolves: [Bug]: Exaggerated presence of errors into the log viewer during syncing of a new macOS device (uplod ndr!) #45899

Summary

Our checkImageSize() & checkImageDataSize() methods always return true if an image is corrupt/invalid¹ (or unreadable). However, when getimagesize() returns false so should checkImage*() IMO.

This current behavior causes already detected invalid images to not only bypass the checkImageMemory() check (as intended), but to continue to be processed in other ways even though they'll fail.

This impacts all formats, not just jpeg (though most are covered by suppressors at this point).

One could argue the current situation is valid behavior since the intention of the checkImage* methods isn't to detect other types of image problems, so it's a bit of an overloaded use. But in all cases I can conceive of, other image manipulations are going to fail anyhow if getimagesize() does. And we're immediately calling getimagesize() once again in many cases.

P.S. With the fix to checkImageSize(), the line with the suppressor shouldn't even be executed any longer. The suppressor added here is just for good measure and to be consistent with the other image formats. If the behavior of the checkImage*() methods is desired to be retained as-is, I can eliminate those changes and keep only the suppressor.

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

Footnotes

1. (or at least corrupt enough their image data can't be retrieved by gd) ↩

[joshtrichards]

/backport to stable29

[joshtrichards]

Thinking more about this, we should probably just use the suppressor and not over-use these other methods...

[artonge]

Is this change on purpose?

[joshtrichards]

No.