Uri scheme isn't normalized

[yecril71pl]

Issue Type: Bug

Open URL <URL: FILE:///proc/sys/fs/inotify/max_user_instances >! Note: <URL: file:///proc/sys/fs/inotify/max_user_instances > opens all right.

VS Code version: Code 1.62.3 (ccbaa2d27e38e5afa3e5c21c1c7bef4657064247, 2021-11-17T08:00:36.721Z) OS version: Linux x64 5.15.5-1-default Restricted Mode: No

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (4 x 2393)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
opengl: enabled_on
rasterization: disabled_software
skia_renderer: enabled_on
video_decode: disabled_software
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|3, 2, 5| |Memory (System)|5.66GB (0.14GB free)| |Process Argv|--unity-launch --crash-reporter-id 2a03cb52-9f4b-48bf-93d3-5c0537d534ee| |Screen Reader|no| |VM|0%| |DESKTOP_SESSION|/usr/share/xsessions/plasma5| |XDG_CURRENT_DESKTOP|KDE| |XDG_SESSION_DESKTOP|KDE| |XDG_SESSION_TYPE|x11|

Extensions (24)

Extension|Author (truncated)|Version ---|---|--- doxdocgen|csc|1.3.2 vscode-pull-request-github|Git|0.32.0 Ionide-fsharp|Ion|5.10.2 better-cpp-syntax|jef|1.15.10 vscode-language-pack-pl|MS-|1.62.4 csharp|ms-|1.23.16 dotnet-interactive-vscode|ms-|1.0.2602010 vscode-dotnet-pack|ms-|1.0.4 python|ms-|2021.11.1422169775 vscode-pylance|ms-|2021.11.2 jupyter|ms-|2021.10.1101450599 jupyter-keymap|ms-|1.0.0 jupyter-renderers|ms-|1.0.4 remote-containers|ms-|0.205.2 remote-ssh|ms-|0.66.1 remote-ssh-edit|ms-|0.66.1 remote-wsl|ms-|0.58.5 cmake-tools|ms-|1.9.2 cpptools|ms-|1.7.1 cpptools-extension-pack|ms-|1.1.0 vscode-markdown-notebook|ms-|0.0.26 vsliveshare|ms-|1.0.5090 vsliveshare-audio|ms-|0.1.91 cmake|twx|0.0.17 (1 theme extensions excluded)

A/B Experiments

``` vsliv368:30146709 vsreu685:30147344 python383:30185418 vspor879:30202332 vspor708:30202333 vspor363:30204092 pythontb:30283811 pythonvspyt551cf:30345471 pythonptprofiler:30281270 vshan820:30294714 vstes263:30335439 pythondataviewer:30285071 vscod805:30301674 pythonvspyt200:30340761 binariesv615:30325510 bridge0708:30335490 bridge0723:30353136 pythonrunftest32:30373476 pythonf5test824:30373475 javagetstartedt:30391933 pythonvspyt187:30373474 vsaa593cf:30376535 vscop804cf:30404767 vscop940:30404999 vsrem710:30405998 ```

[yecril71pl]

[renderer1] [error] Unable to resolve resource FILE:/proc/sys/fs/inotify/max_user_instances: Error: Unable to resolve resource FILE:/proc/sys/fs/inotify/max_user_instances at a.doCreateReferencedObject (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:2377:109131) at a.doCreateReferencedObject (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:2377:109094) at async i.acquire (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:17:32322) at async u.createModelReference (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:2377:110767) at async is.resolve (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:1740:45776) at async il.setInput (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:2342:109954) at async n.doSetInput (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:2342:34632) at async n.doOpenEditor (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:2342:33032) at async n.openEditor (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:2342:32680) at async vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:2544:16967 at async S.doOpenCodeEditor (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:1301:28423) at async m.open (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:603:18052) at async a.open (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:603:19565)

[JacksonKearl]

cc @bpasero, based on the RFC here it seems we should be normalizing URI schemes to lowercase.

An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the sake of robustness but should only produce lowercase scheme names for consistency.

[jrieken]

Yeah, this is a known bug. What's unknown is if we can still fix it. Many 3rd parties and extensions have started to "depend" on uri-bugs and in the past good changes/fixes had really bad consequences. This needs careful consideration first

[jrieken]

Potential code changes are in joh/low-uri-scheme.

[jrieken]

Doing the lower-case during toString() is a small change and one test is failing (workingCopyBackupService.test.ts): https://github.com/microsoft/vscode/runs/4431032472. @bpasero can you asses the failure. Is the scheme casing something that's persisted or not?

[bpasero]

@jrieken this was a lucky one to catch because it would result in data loss if going unnoticed. The test is using the following scheme:

https://github.com/microsoft/vscode/blob/fe227dacb71c40c38e91a5f59a407f6c37def728/src/vs/workbench/services/workingCopy/test/electron-browser/workingCopyBackupService.test.ts#L139

And backups are associated with a backup ID that is the hash of the resource. If now the resource changes (the scheme lowercases), the backup ID would likely change and existing backups would no longer be found.

Not as bad as loosing all file or vscode-file backups, but potentially for extensions that introduce a scheme that uses uppercase.

[jrieken]

Not as bad as loosing all file or vscode-file backups, but potentially for extensions that introduce a scheme that uses uppercase.

Is this something that you can prepare for so that no backups are lost?

[bpasero]

Not impossible, but requires a migration step to open each and every backup to figure out the URI value (we store that in the backups as meta data).

https://github.com/microsoft/vscode/blob/fe227dacb71c40c38e91a5f59a407f6c37def728/src/vs/workbench/services/workingCopy/common/workingCopyBackupService.ts#L339-L341

And then rewriting the backup under a hash that accounts for the new form.

Not sure there would be more pitfalls on the way? E.g. we often use the URI resource as a key to associate something to (even editor state). If the toString form of a URI changes, a lot of things would get broken I think.

[jrieken]

Not sure there would be more pitfalls on the way? E.g. we often use the URI resource as a key to associate something to (even editor state). If the toString form of a URI changes, a lot of things would get broken I think.

There is no problem as long as externalized uris go though URI.parse(...).toString() again. Tho every place where a scheme is "left alone" or were an externalized URI is concatenated with another string we can see issues

[vscodenpa]

We closed this issue because we don't plan to address it.

Thanks for your understanding, and happy coding!

[jrieken]

This is acknowledged but I don't wanna take the risk and regressions that changing this will likely cause