Git diff of too large image file: Unsupported text encoding and NaNTB

[benurb]

• VSCode Version: 1.23.1
• OS Version: mac OS 10.13.4 High Sierra

Steps to Reproduce:

1. Create git repo
2. Create an image file that is larger than the limit for the built-in image preview and commit it to the repo
3. Replace it with a smaller image and look at the diff from the source control view
4. It shows "The file is not displayed in the editor because it is either binary or uses an unsupported text encoding." instead of the preview of the large image. Furthermore it shows NaNTB as file size of the previous image in the status bar.

Does this issue occur when all extensions are disabled?: Yes

[bpasero]

/cc @mjbvz for the status bar bug

[bpasero]

Actually, giving it to you @mjbvz because it seems to me that also the left-hand binary view should read this instead: The file is not displayed in the editor because it is too large

[bpasero]

I pushed a fix to not draw NanTB in the status bar if the size is not known.

[mjbvz]

I've confirmed that we no longer show the NaN TB in the status bar.

We still do not show anything helpful on the left side of the editor for large image however. This root cause is that for the left side resource, VS Code uses a uri such as "data:%3Blabel%3Abig.png%3Bdescription%3AHEAD%2C". I believe that these uris are created here by the git extension:

vscode/extensions/git/src/commands.ts

Line 350 in 1cd6bd6

if (size > 1000000) { // 1 MB

@joaomoreno Do you have ideas on if or how we could handle this case better? Should we use the label in the data uri to try to detect that the file is an image?

[joaomoreno]

Would this be solved by using an FS provider for git resources and moving away from the TextDocumentContentProvider?

cc @bpasero

[joaomoreno]

Since the 1MB is a well known limitation of the current approach, I'm removing myself from this October issue. FS Provider might be a solution, but definitely not for October.

[bpasero]

@joaomoreno my understanding is that this data is flowing around via data-URIs, no?

I think, yes, a file system provider for Git is ideal for all cases 👍

[joaomoreno]

Yes, but that's because Git still uses the once-upon-a-time-was-the-only-thing-available TextDocumentContentProvider... if we were to switch to the FS Provider, couldn't we send binary files as well?

[bpasero]

@mjbvz should comment on that, since he rewrote the binary viewer as extension, I am not sure how binary data is shown.

[mjbvz]

@joaomoreno Yes, if git returned a uri that points to a custom file system provider, it could provide binary data as well

[joaomoreno]

#55110

[mjbvz]

Ok, thanks. Closing this as a duplicate of #55110 then