We tried this in Ubuntu today and it didn't work either.

Let me summarize:

• On both Windows and Linux this works if Code is already running. It doesn't work in neither platform if Code isn't already running.
• On macOS everything works as expected, regardless.

Did I get that correctly?

Yes, that’s correct.

Any update here? This flow seems completely broken, and we've been waiting for over a month @joaomoreno

No update. Feel free to investigate and submit a PR for this.

It doesn't work on Mac for me either... Code has to be open for clone to work.

I am looking into this.

@joaomoreno the problem is the class ExtensionUrlHandler registers itself as url handler upon instantiation, and it's instantiated too late.

The solution is probably to instantiate it earlier, but finding the appropriate place to do this is too difficult for me.

So who can we contact who can help out? We'd like to use this flow more, not less, and as it stands it's still broken.

@joaomoreno, just to clearify:

When we receive the request to open the url, the extension (Git) hasn't registered a handler yet.

The class I linked to is supposed to buffer url requests until the extension is active. Problem is it's not registered itself yet. It's only registered upon instantiation.

The instantiation happens when the class is injected (mainThreadUrls) There is probably a way to to cause early instantiation, but how and where to do it is beyond me without some guidance.

When we receive the request to open the url, the extension (Git) hasn't registered a handler yet.

It doesn't have to. Every vscode://EXTENSION.ID/* URI will automatically activate the extension with id EXTENSION.ID. Unless there's a bug in that mechanism, but the implementation is there: https://github.com/Microsoft/vscode/blob/d0c362792aa27ae6b6648f8b99d8d78e6095d537/src/vs/workbench/services/extensions/common/inactiveExtensionUrlHandler.ts

@joaomoreno for the code you linked to to run the class has to first register itself with the urlService, which it does in the constructor (here). When the request arrives the constructor hasn't run yet.

Possibly broken by 819dda9 cc @jrieken

Possibly broken by 819dda9 cc @jrieken

How? That commit renames a file and appends a new line?

🤦‍♂️ You're right. I meant this: 900d58b cc @bpasero

@joaomoreno unlikely, I do not see anything changing. Previously you would do:

serviceCollection.set(IExtensionUrlHandler, new SyncDescriptor(ExtensionUrlHandler));

and now it is:

registerSingleton(IExtensionUrlHandler, ExtensionUrlHandler);

It is now actually even called earlier than before.

@bpasero I'm pretty sure this is what broke it. As a fix, I was forced to change registerSingleton into registerWorkbenchContribution with LifecyclePhase.Ready since on the main side since Ready is the only state propagated to the main side. If more window states would propagate to the main side, we could change it to other another state, ie Eventually.

Argh... reverted... this needs to be a service. 🤦‍♂️

It is now actually even called earlier than before.

@bpasero I don't think this is true at all. My singleton ctor is running well after the lifecycle Ready event starts. Even after Restored. And it was running before Ready for sure.

I could not find a better fix than adding a setTimeout, do you have better ideas here?

To repro, just run:

./scripts/code.sh --open-url code-oss://vscode.git/clone

It should show a native confirmation dialog. It currently doesn't.

@joaomoreno as discussed, the difference from before is that services are no longer created on startup unless they are needed. A combination of this service and an early workbench contribution could work.