Web Browser Support for Git Graph

[akosyakov]

I'm trying to run this extension in Gitpod (www.gitpod.io) and it does not work because of following errors:

Refused to load the stylesheet 'https://webview-3000-effc65ad-3dce-41f1-8f56-5afd32db8b58.ws-eu01.gitpod.io/webview/theia-resource/file/workspace/theia/plugins/vscode-git-graph/media/out.min.css' because it violates the following Content Security Policy directive: "style-src vscode-resource: 'unsafe-inline'". Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback.

(anonymous) @ main.js:458
main.js:458 Refused to load the script 'https://webview-3000-effc65ad-3dce-41f1-8f56-5afd32db8b58.ws-eu01.gitpod.io/webview/theia-resource/file/workspace/theia/plugins/vscode-git-graph/media/out.min.js' because it violates the following Content Security Policy directive: "script-src vscode-resource: 'nonce-GoiviazGVsJ9obznH3AxC8hcldjEI01I'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

(anonymous) @ main.js:458
index.html:1 Refused to load the stylesheet 'https://webview-3000-effc65ad-3dce-41f1-8f56-5afd32db8b58.ws-eu01.gitpod.io/webview/theia-resource/file/workspace/theia/plugins/vscode-git-graph/media/out.min.css' because it violates the following Content Security Policy directive: "style-src vscode-resource: 'unsafe-inline'". Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback.

It happens because the extension is designed to run only in local context, i.e. it expects resource URI always starts from vscode-resource scheme, which cannot run in remote context. Here is the explanation how to reconfigure extension that it supports local and remote context at the same time: https://code.visualstudio.com/api/advanced-topics/remote-extensions#using-the-webview-api

In short one has to use script-src ${panel.webview.cspSource}; style-src ${panel.webview.cspSource}; instead of limiting to vscode-resource scheme. And to create URIs to fetch some resources, i.e. images, use asWebviewUri

[mhutchie]

Thanks for raising this feature request!

I closely monitor all new functionality available in Visual Studio Code and was keen to adopt this when it was introduced in Visual Studio Code 1.38.0.

As much as I would like to enable this capability so the extension can be used for applications outside of Visual Studio Code itself, it would force me to upgrade the minimum version of the extension (currently 1.31.0) by seven releases of Visual Studio Code (to 1.38.0). From the information I have, a fairly significant portion of Git Graph users haven’t upgraded to Visual Studio Code 1.38.0. All of these existing users would no longer be able to receive new upgrades to Git Graph.

As the number of Git Graph users that would loose access to all new updates of the extension is far greater than the number of users that would benefit from using this new feature, it doesn’t make sense for me to change the minimum version requirement of Git Graph at the present time.

I definitely want to support this functionality, and will definitely do so in the future once more users meet the minimum version requirement of Visual Studio Code.

I’ll close this feature request for now and move it to the backlog, however I’ll definitely open it again and implement it once it is appropriate to do so.

[akosyakov]

It should be possible to only update typings and then do runtime check. If api is missing then fallback to the previous approach. In such way you won’t break users, but you can still use new apis if they are available. Our user are asking for it: https://community.gitpod.io/t/vscode-extension-support/180/23

[mhutchie]

I understand that upgrading the typings and doing a runtime check would get this feature working, however it also means that during development the typings cannot be trusted at all. Upgrading the typings would make it appear that all of the other new Visual Studio Code functionality is available even though it’s not, hiding the need for a runtime check (causing compatibility bugs).

It’s definitely not good practice to have the version of the typings different from the minimum version requirement of the extension. I don’t think that enough users currently would benefit from this change (you’re the second person to raise it), to break best practice and significantly increase the risk of introducing breaking, hard to detect, compatibility bugs to large numbers of users.

Note to other users reading this thread: If you would like to use Git Graph outside of Visual Studio Code, please like the first comment in this thread. This will let me gauge community interest and help me implement this as soon as it’s reasonable to do so.

[akosyakov]

I understand that upgrading the typings and doing a runtime check would get this feature working, however it also means that during development the typings cannot be trusted at all. Upgrading the typings would make it appear that all of the other new Visual Studio Code functionality is available even though it’s not, hiding the need for a runtime check (causing compatibility bugs).

You can add d.ts amending vscode namespace. It would allow to add optionally new features without bringing the rest + typescript will force you to make checks at the compilation time.

[akosyakov]

@mhutchie Would it be possible to keep an issue open at least? I believe it is the actual and was not addressed.

[mhutchie]

Hi @akosyakov,

Manipulating the VSCode namespace in a custom d.ts file would definitely get around the issues I previously mentioned, but it is still hardly a good practice solution to have runtime checks to test compatibility.

As I mentioned in one of my previous replies, I just closed this issue temporarily until the Git Graph users Visual Studio Code compatibility is sufficient to implement it. I added the “Backlog” label to this feature, which indicates it is only temporarily being closed until a later point (as I definitely want to implement this feature in the coming months).

I only keep issues open that are actively being considered for implementation in upcoming releases. As soon as the user compatibility is sufficient, I’ll definitely re-open and implement this feature request.

Additionally, if I was to implement this feature with a runtime check, it sends the message to other users that I’m happy to implement temporary work-arounds for any other new features in Visual Studio Code. All of a sudden, instead of just one work-around there are heaps of them and the extension codebase is a mess. Each work around then needs to be tidied up at a later date when the minimum version requirement of the extension is sufficient, leading to additional work. I’ve found that working on this extension with such a large user community that it is necessary to act consistently and not make exceptions, otherwise some users get upset that they are not being treated fairly.

FYI: After the big upcoming release of Git Graph v1.22.0 this next weekend, which is my current focus, I’ll have a look at possible solutions and see if there is any short term solution that I’ll be comfortable implementing temporarily (that I could implement and make available in Git Graph v1.23.0).

[tstibbs]

For anyone coming here hoping to find a way to get it working themselves as a stop gap until git-graph uses more recent typings, this branch should work for you: https://github.com/tstibbs/vscode-git-graph/tree/271-support-remote-context

[mhutchie]

Support for this will be available in Git Graph 1.24.0, as tracked by #305.

[mhutchie]

I've just upgraded the minimum version requirement of Visual Studio Code from 1.31.0 to 1.38.0, and migrated to use asWebviewUri & cspSource in #305. These changes are in v1.24.0-beta.2, which can be installed following the instructions provided here.

However, there are still several UI fixes that need to be addressed before Git Graph can support being run outside of Visual Studio Code. I'm re-opening this issue to track the delivery of all these remaining items. I expect to complete and release them this weekend.

[tstibbs]

I can confirm that the specific issue mentioned raised here (CSP issues in gitpod) is fixed in the beta release.

[mhutchie]

This will be available in v1.24.0, which will be released in the next day. I'll reply to this thread with the published .vsix when it is available.

Git Graph officially supports Visual Studio Code in Microsoft's Visual Studio Codespaces in the Google Chrome browser, however the underlying changes allow Git Graph to be supported in most third-party Visual Studio Code browser-based platforms, and in most popular web browsers.

I'd like to thank everyone for their patience over the last few months on the journey to make Git Graph available in web browsers.

I'd also like to thank @tstibbs who kindly helped out with resolving the context menu compatibility issue.

FYI: I've noticed a couple of minor discrepancies / bugs with Gitpod's implementation of the corresponding Visual Studio Code extension integrations, that will affect all extensions using them. These are isolated to Gitpod (not present for any other providers I've tested), so I'm sure the Gitpod team will be able to resolve these over time.

[mhutchie]

This is now available in v1.24.0, which you can download here. It can be manually installed in Visual Studio Code following these instructions, or in third-party products following their own instructions.