Hi,
A simple use case of a full public Image URL field being set as “File Viewer” widget only shows the preview on the “Table View” but not in “Details” or “Smart View”.
Here is how it looks on the “Table View”:
The field contains the full path to the image. Here is an example URL:
https://res.cloudinary.com/wescover/image/upload/c_limit,f_auto,q_auto,w_2000/v1/ar08-b
Note - No “extension” on those links - serves best-supported extension like webp for chrome, but also when using an explicit extension like “png” the same problem remains.
This also works and forces “png” file:
https://res.cloudinary.com/wescover/image/upload/c_limit,f_auto,q_auto,w_2000/v1/ar08-b.png
Expected behavior
Smart View and Details would also show the preview of the image.
Actual behavior
An error appears “Missing prefix to base64 data”.
Failure Logs
No errors in the browser console.
Context
Please provide any relevant information about your setup.
- Browser: Chrome Version 81.0.4044.138
- OS: Mac osx
Hi Yoad_Snapir,
Thanks you for pointing this issue.
I am able to reproduce it locally.
Effectively, it looks weird that we are able to display the image in table view but not in other views.
I’ve just created a bug entry for that point, you will be informed about the resolution soon.
Regards
Hi again,
For your information, it is actually working with any other images.
For example any image link from google image display correctly in SummaryViews.
Of course it’s still a weird behavior on our side to have it working in TableView and failing in SummaryView, but consider that this bug does not appear with every image.
Regards
So could it be related to the image format? I.e. WEBP vs jpg vs png?
Following is one working example in each format, at a first sight it is not related to format but I maybe miss some details.
https:/ /www.gstatic.com/webp/gallery/1.webp
https:/ /www.pngfind.com/pngs/m/123-1231163_980-x-980-1-example-icon-hd-png.png
https:/ /upload.wikimedia.org/wikipedia/commons/thumb/6/6c/Shack_in_Pigeon_Forge%2C_TN_by_Zachary_Davies.jpg/1200px-Shack_in_Pigeon_Forge%2C_TN_by_Zachary_Davies.jpg
I narrowed it down to those two almost identical image URIs:
Fails:
https://rs.wescover.com/image/upload/f_auto,q_auto/v1/ar08-b
Works:
https://rs.wescover.com/image/upload/f_auto/v1/ar08-b
https://rs.wescover.com/image/upload/q_auto/v1/ar08-b
It’s not about the content of the image “bytes” - it’s the URI itself.
So as you see - the “,” (comma) mark in the URL is that causes the different. Most likely somthing about the data URI generation code fails to parse the comma as a proper part of the URI.
We need to use commas since this is the syntax of our CDN provider - and I believe this is a valid URI character to use. (See RFC3986 “reserved” delimiters).
wdyt?
1 Like
Makes sense. Let’s add this detail to the bug ticket.
Thank you.
1 Like
Hi @Yoad_Snapir,
The patch is currently under review and should be live tomorrow if everything goes well.
Thanks for your patience!
1 Like
