Protocol links do not work in Firefox

[JacksonKearl]

91225 on ubuntu

Have a workspace open in web.

Have some other folder open in insiders

Close insiders

Click "open in desktop"

Bug: Insiders opens to the folder it opened last, rather than the workspace I had open in web.

[bpasero]

Since this works fine on Windows and macOS, I suspect an issue with how we support to open links on Linux. Maybe we are missing to forward the right parameters?

[bpasero]

@JacksonKearl actually this works fine for me if I use the latest build: https://az764295.vo.msecnd.net/insider/b0be0672c210f1fa76109ce675365bb785657e84/code-insiders_1.43.0-1582695407_amd64.deb

Did you use an older build maybe? Or possibly snap?

[JacksonKearl]

This is only a bug in firefox, as firefox does not delegate to xdg-open for URI's. Chrome is good.

[bpasero]

@JacksonKearl did you find the bug in Firefox or would you be willing to report one?

[JacksonKearl]

@bpasero I'd like to figure out what URI Insiders is actually being opened with in order to get more info, but I cant seem to get a handler for the code-oss scheme to register, even for xdg-open. Do you have ideas on how to get a more concrete repro?

[bpasero]

@JacksonKearl follow the usages of urlProtocol from https://github.com/microsoft/vscode/blob/fc9543ac88a6ddd541d319d6425e1734ccb36f72/product.json#L22. That is what we use to register a handler with the OS. However for Linux it seems we are also needing this to work: https://github.com/microsoft/vscode/blob/fc9543ac88a6ddd541d319d6425e1734ccb36f72/resources/linux/code-url-handler.desktop#L1

Would be great to isolate this into a standalone repro.

[JacksonKearl]

@bpasero I looked further into this and set up my own url handler that simply writes the arguments it gets to a file:

#!/bin/bash

OUT="/home/parallels/echoer_out";

echo "New Invocation" >> $OUT;
echo "$@" >> $OUT;

and found that in both Firefox and Chrome the same argument info is being passed:

New Invocation
vscode-insiders://vscode-remote/localhost:9777/home/parallels/testworkspace.code-workspace
New Invocation
vscode-insiders://vscode-remote/localhost:9777/home/parallels/testworkspace.code-workspace

which would seem to suggest its not actually a Firefox problem?

[bpasero]

@JacksonKearl the URL seems fine to me. What does xdg-open vscode-insiders://vscode-remote/localhost:9777/home/parallels/testworkspace.code-workspace result in on your Linux?

[JacksonKearl]

I'm actually now able to reproduce this on both firefox and chrome, but it's flakey on both. Directly calling xdg-open seems to work reliably.

[JacksonKearl]

This is what I'm seeing:

1. Start server, with either Safari or Chrome as default broswer
2. Run xdg-open in terminal. Works.
3. attempt to open in desktop. fails
4. open new tab to the remote, attempt to open in desktop. fails.
5. open new window of same browser to remote, without closing old. Attempt. Fails.
   1. open new window of different browser to remote. Attempt. Works.
6. After opening in alternate browser works, attempt in original window. Fails.
7. close original window. open a new window of the same browser. Attempt. Works.

This all reproduces reliably across defualt browser chrome or firefox. The summary seems to be:

1. Calling xdg-open with the URI always succeeds.
2. Invoking Open in Desktop in your default browser (the one web.sh spawns) will fail if you have not fully shut down all windows of that browser after it was spawned by web.sh, and succeed otherwise.
3. Invoking Open in Desktop from a browser of a different type than the one web.sh spawned always succeeds.

So I can:

1. run web.sh, get a new Chrome.
2. Open a seperate chrome window, to home page.
3. Close original window.
4. Open a new window.
5. Close the window that was just on home page.
6. In the remaining window, got to the remote. Open in Desktop will fail.

The browser that web.sh spawned must be fully shut down after it has been spawned by web.sh, and then reopened, in order for Open in desktop to work in its windows. This hold across Chrome and Firefox.

[bpasero]

@JacksonKearl for the sake of testing, let's ignore that the workspace when opened in desktop is functional or not. "Open in Desktop" is known to actually not work well for localhost testing. For the sake of testing, consider the test as success if you see this in the status bar:

Here is again how it works for me using Firefox:

Can you completely uninstall VSCode insiders and reinstall from the deb package?

Last, how does the situation look like when you try normal file protocol links and not vscode-remote, e.g. vscode-insiders://file/<path>?

[vscodebot[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[bpasero]

This still needs more info from https://github.com/microsoft/vscode/issues/91496#issuecomment-594353613

[JacksonKearl]

I do not get vscode-remote in the status bar in any of the failure cases.

Navigation to a vscode-insiders://file/... URI gives similarly broken behaviour.

[bpasero]

Ok, then this seems unrelated to "Open in Desktop" but a general issue.

[JacksonKearl]

It isn't just Firefox. A more accurate title might be "Protocol links do not work in the browser instance spawned by web.sh"

[bpasero]

@JacksonKearl so is this the gist of the issue that protocol links work when you manually open a browser?

[JacksonKearl]

@bpasero yeah that seems right

[bpasero]

Ok, that does not seem like it has impact on users then. I am using the opn library to open a browser but you can pass --launch=false to prevent the browser from opening.

I can only speculate that possibly protocol handlers require the app to be started using the dock and not from the command line.

[vscodebot[bot]]

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!