StorageFile.GetThumbnailAsync does not generate thumbnails for OneDrive files

[lmadhavan]

Describe the bug

StorageFile.GetThumbnailAsync generally triggers generation of a thumbnail if one doesn't already exist for the specified file. This works for local files, however for files that are stored on OneDrive, it simply returns a placeholder image unless a thumbnail was already generated previously by File Explorer.

Steps to reproduce the bug

1. Create a folder in OneDrive and add a photo to it (make sure the folder is not available locally, for example by using the web UI).
2. Call GetThumbnailAsync on the photo. The call succeeds but simply returns a placeholder image. File Explorer initially displays the same placeholder for the folder icon.
3. Navigate inside the folder using File Explorer. This triggers generation of the thumbnail, after which both GetThumbnailAsync and the folder icon display the correct thumbnail.

Expected behavior

GetThumbnailAsync should trigger the same code path as File Explorer to generate the thumbnail, unless ThumbnailOptions.ReturnOnlyIfCached is specified, in which case it should return null as specified in the documentation. Returning a placeholder when the thumbnail has not been generated makes it impossible for the app to tell if the call actually succeeded or not.

Screenshots

Before thumbnail has been generated:

After thumbnail has been generated:

NuGet package version

No response

Packaging type

No response

Windows version

May 2021 Update (19043)

IDE

Visual Studio 2019

Additional context

No response

[riverar]

Hi @lmadhavan 👋

Sorry to redirect you, but this is not the right place for UWP discussions. This repository is focused on the Windows App SDK.

Here's some alternate resources:

• Microsoft Q&A windows-uwp tag: Has a dedicated support staff that helps answer questions there.
• UWP Community Discord: Very tight-knit and supportive community.
• Stack Overflow

[lmadhavan]

It's not clear that this issue is specific to UWP, GetThumbnailAsync is likely just calling into the shell thumbnail handler so this might be a deeper platform issue (as evident from the inconsistencies even in File Explorer). Perhaps this isn't the right repository for that either but I do see a bunch of other file access issues/proposals here.

There is already a similar question on Stack Overflow that was opened in 2017 but never received any answers.

[ghost]

Sorry to redirect you, but this is not the right place for UWP discussions. This repository is focused on the Windows App SDK.

Sorry to re redirect you, but this is not the right place for UWP Redirection templates. This repository is indeed focused on the Windows App SDK.

Windows App SDK is not something that rests on thin air. It rests on WinAPIs targeted at Windows Devs. You and I know what UWP is and isn't. Since you still felt the need to mention the cursed word, I'm going to proceed anyway. UWP = CoreWindow, nothing more nothing less. Windows App SDK's WinUI 3 =AppWindow and Windows.Storage.* apis brokered WinAPIs.

Can AppWindow theoretically use Storage apis ? Yes.
Are WinAPIs relevant to Windows App SDK ? Off Course Yes.

Therefore OP's issue is 100% relevant. [[[ and I may need not refer dozens of WinAPIs proposals lying in this very repository where some are by the very Microsoft officials. ]]]

[andrewleader]

Thanks for the discussion folks about whether this is the right place for bugs like this (WinRT OS APIs that are usable by both UWP and desktop apps). We'd love your feedback on that topic, please share your thoughts here: #1876

Until we make a decision on that (we've started to discuss this topic internally too about what to do with OS API bugs), we'll leave this open with the transfer-to-platform tag like a few other similar issues.

[jonwis]

Super interesting, but not a WASDK issue. I've filed http://task.ms/49323440 for @RobertStPierre or @luedersj to look into.