| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
The TYPE parameter of PHOTO is optional, but getPhotoUrl() called toLowerCase() on it unconditionally. Contacts stored e.g. as 'PHOTO;ENCODING=b:…' (without TYPE) threw a TypeError and showed initials instead of the photo, while other CardDAV clients displayed them fine. Detect the image type from the magic bytes of the base64 data when the TYPE parameter is missing. Unknown signatures fall back to jpeg, which browsers happily content-sniff in an img element anyway. Also log the contact itself in getPhotoUrl() error messages instead of the undefined this.contact. Resolves nextcloud#5401 Assisted-by: Claude:claude-fable-5 Signed-off-by: MiMoHo <37556964+MiMoHo@users.noreply.github.com>
Codecov Report❌ Patch coverage is 88.88889% with 1 line in your changes missing coverage. Please review.
📢 Thoughts on this report? Let us know! |
Sorry, something went wrong.
| const signature = Object.keys(signatures).find((signature) => photoB64Data.startsWith(signature)) | ||
| // browsers detect raster images in an img element from the content, | ||
| // so a wrong subtype still renders fine | ||
| return signature ? signatures[signature] : 'jpeg' |
There was a problem hiding this comment.
@SebastianKrupinski: I don't know if we should do such a fallback here. I think adding a warning or something like this would make more sense?
Sorry, something went wrong.
|
Hey @MiMoHo, thank you very much for your first PR here! Looks pretty good and useful to me. But additional colleagues will have a look into it as well. |
Sorry, something went wrong.
Address review feedback on nextcloud#5565: instead of silently assuming JPEG for a PHOTO whose magic bytes match no known signature, log a warning so the guess is visible in the console. The fallback itself stays, as browsers content-sniff raster images in an img element regardless of the declared subtype. Add a test for the unknown-signature path, closing the coverage gap codecov reported on the fallback branch. Assisted-by: Claude:claude-opus-4-8 Signed-off-by: MiMoHo <37556964+MiMoHo@users.noreply.github.com>
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
Sorry, something went wrong.
| */ | ||
| function detectImageType(photoB64Data) { | ||
| // base64 encodings of the magic bytes of the common image formats | ||
| const signatures = { |
There was a problem hiding this comment.
We only allow upload of PNGs, GIF, SVG, JPEG, WebP and AVIF. Could you please change the signatures accordingly? See
Sorry, something went wrong.
There was a problem hiding this comment.
Please change the image types acceptable for displaying. Once that is done, it get's a go from my side.
Thanks!!
Sorry, something went wrong.
| if (!signature) { | ||
| // browsers detect raster images in an img element from the content, | ||
| // so an assumed subtype still renders fine, but warn about the guess | ||
| console.warn('Could not detect the photo type from its content, assuming JPEG') |
There was a problem hiding this comment.
console is not accepted by out linter anymore. Please use logger instead.
See : #5624
Sorry, something went wrong.
|
Hey @MiMoHo, are you able to implement the requested changes? Or should we do the last steps for you? Thanks for the feedback! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Summary
Contact photos stored without an explicit TYPE parameter, e.g.
were not displayed: getPhotoUrl() called photoType.toLowerCase() on the missing parameter and threw
so the app fell back to initials, while other CardDAV clients (eM Client, iOS Contacts) display these photos fine. The TYPE parameter is optional per RFC 2426/6350.
Changes
Checklist
Resolve #5401
🤖 Generated with Claude Code