cloudinary / cloudinary-react

React components that utilize Cloudinary functionality
MIT License
502 stars 219 forks source link

Images in chrome are not displayed when fetchFormat="auto" #233

Closed yardz closed 3 years ago

yardz commented 3 years ago

Describe the bug in a sentence or two.

On Google Chrome when fetchFormat="auto" option is set the images are not displayed. Only with devtools open when simulating a mobile (any iPhone)

Describe the desired/expected behavior.

I think it would be interesting to solve this problem, but if it is not possible (or not easy), to put a note in the documentation about this behavior. I wasted several hours trying to fix this believing it to be a problem with my code. A note in the documentation would have been enough for me not to worry. I believe other people go through the same problem.

Link to reproduction of the issue on codepen/jsfiddle/etc.

https://codesandbox.io/s/distracted-napier-y2mjm?file=/pages/index.js:169-174

Issue Type (Can be multiple)

[ ] Build - Can’t install or import the SDK [ ] Babel - Babel errors or cross browser issues [ ] UI/Performance - Display or performance issues [x] Behaviour - Functions aren’t working as expected (Such as generate URL) [ ] Documentation - Inconsistency between the docs and behaviour [ ] Incorrect Types - For typescript users who are having problems with our d.ts files [ ] Other (Specify)

Steps to reproduce

This bug only occurs in chrome with devtools open simulating a mobile (any iPhone model)! In codepen there is a minimal reproduction of the code, but in the integrated browser it is not possible to reproduce the error.

To reproduce the bug follow the steps: 1- copy the url from the codepen browser (https://y2mjm.sse.codesandbox.io/). 2- Open the url in chrome. 3- Open the chrome debug, and select the mobile option (any iPhone). 4- Update the chrome page (it is important to update the page).

Additional Details: I noticed that the error doesn't happen with demo images. That's why I used the public images of my project. I also noticed that in other browsers when simulating some devices the same error also occurs, I suspect it's because of the "user agent" (I'm reporting in chrome because that's where I found the bug.)

This is an important detail, when we have several images on the page, sometimes some of them work correctly, but this behavior is not constant (the error is constant).

Error screenshots

Captura de Tela 2021-07-24 às 4 23 39 PM

Browsers (if issue relates to UI, else ignore)

[ x ] Chrome [ ] Firefox [ ] Safari [ ] Other (Specify) [ ] All

Versions and Libraries (fill in the version numbers)

Cloudinary-core - 2.11.3 Cloudinary-react - 1.7.0 React - 0.0.0 Node - 16.4.0 NPM - 7.18.1

Config Files (Please paste the following files if possible)

{
  "name": "nextjs",
  "version": "1.0.0",
  "scripts": {
    "dev": "next",
    "build": "next build",
    "start": "next start",
    "post-update": "yarn upgrade --latest"
  },
  "dependencies": {
    "cloudinary-react": "1.7.0",
    "next": "11.0.1",
    "react": "17.0.2",
    "react-dom": "17.0.2"
  },
  "license": "MIT",
  "keywords": [
    "next"
  ]
}
patrick-tolosa commented 3 years ago

Hi @yardz, Thanks for the detailed description.

I can confirm you've indeed stumbled into what appears to be a bug, but please let me shed some light on the matter:

Automatic fetch format, or as we call it f_auto uses the browser's user agent to deliver the best format for the current user. For Safari users (iPhones, iPads), this usually means thejp2 image format.

When you use the devtools with any iPhone or iPad models, chrome sends the request to Cloudinary disguised as a Safari:

user-agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1

Our servers assume it's a real user, and deliver a jp2 image. Unfortunately, Chrome does not support jp2 and cannot load it.

Results may vary

Not all images that go through f_auto will return the same format. The actual algorithm takes into account various parameters in the decision and not just the user agent, which means that for some images the devtools might work, while for others it won't.

That aside, I'll take this internally for more discussions. What message would you feel would be helpful for future users?

yardz commented 3 years ago

@patrick-tolosa thanks for the quick response. I believe a simple note in the documentation (https://cloudinary.com/documentation/react_image_manipulation#converting_to_another_image_format). "Attention, when using dev tools to emulate other devices with fetchFormat="auto" some images can fail due to the user-agent and format received." Any message like this, that put this disclaimer will help a lot when someone faces this problem.

Once you understand the reason for the bug, the behavior is quite obvious, but until you get to that answer, it is very difficult to understand what is happening. To be honest, I don't even know if it's fair to classify the behavior as a Bug. I believe cloudnary is working as it should but it would be really nice to have that explanation in the documentation.

aleksandar-cloudinary commented 3 years ago

Hi @yardz, Thanks for sharing your findings. It can definitely be confusing if you're running into it for the first time.

While there isn't a note directly under the fetchFormat section on the React page, there is a note under the f_auto section here: https://cloudinary.com/documentation/image_transformations#f_auto

That said, there are a number of sections regarding f_auto so you might not have come across that one.

As Patrick mentioned, we'll follow up internally with our Documentation team to see how it can be improved.

patrick-tolosa commented 3 years ago

@yardz I'm closing this issue as it appears resolved, please let us know if you have any other issues.