$core_v2_ui.GetPreviewHTML() returns inconsistent markup

Hi there,

The default Media - File List widget in 10.1.3.8316 is responsible for creating a list of files and includes a snippet of markup for rendering preview images/icons:

$!core_v2_ui.GetPreviewHtml($media.File.FileUrl, "%{width=100,height=100}") 

For some reason, the preview images created from this are inconsistently rendered as URLs or <img> tags containing URLs based on the file type:

Preview icon for files sometimes load images, sometimes link text

The URLs for PDF and PPTX files appear to be valid even though they aren't wrapped in an <img> tag to render them properly:

PowerPoint preview icon loads properly in a web browser

Is this the expected behavior? It doesn't behave this way in 10.0.2.

Parents
  • I'm not able to reproduce this. I noticed both of the files in question are Office documents. Do you have the Document Viewer extension enabled? If so, is it showing any errors? Are the files listed in its Documents tab?

  • Hi ! I just ran through the process again with the default widget in a new group. The Document Viewer extension is on and does not show any exceptions.

    When it's enabled, the broken thumbnails are seen in the file list for Office documents.

    I checked the Job Server and it's running in the background:

    Once I disable the Document Viewer, I do see the filetype icons:

    I just opened the Events panel and no IFilter could be found for the documents. I'll try reinstalling the Office Filter Packs and see if that resolves the problem.

  • Okay, I can see the thumbnails once I try accessing each file and the Document Viewer finishes creating a preview, but the ugly URL text shows up in place of an image until the thumbnail is generated. That's not going to make people happy if the Document Viewer falls way behind processing documents. I had to disable the Document Viewer in 9.2 after the number of incoming documents overwhelmed the capacity of the conversion process: hundreds of homework assignments all posted at the end of a day... you get the idea. 24 hours or more is a long time to have a broken/incomplete UI for files, especially when the files in question have a limited relevance time window. Grimacing

    Is the Document Viewer significantly faster in 10.x? If not, I'd like to see the UI degrade more gracefully when the Document Viewer falls behind processing files.

  • Document Viewer is the same in 10 as it was 9.  The bad text is known and we will be looking at it shortly:

    TE-9108: Listing for files that have not been converted yet shows missing image references

    Completed for 10.2.2.4296, 10.1.10.11792

Reply Children
No Data