Missing prefix to base64 data - Image Preview Widget Not Working in "Details" View

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”:
image

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”.
image

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

The patch is live :raised_hands:t3: