Our current deployment, I think, is somehow breaking the URL Handler. This becomes more severe when trying to use any plugin that requires authentication. Sometimes, it possible to use the backup URL Handler, but, only if the plugin is developed with the feature (most of MS and GitHub's are). Reproducible: Always
Created attachment 792446 [details] emerge --info
Created attachment 792449 [details] emerge --info app-editors/vscode
Hello, Do you think the .desktop entry needs some fixing? Can you give me a use case to reproduce this ? I'll try to figure it out in the upcoming days.
Hey Adel, Maybe. I've also noticed that when you use the 'New Window' or 'New Empty Window' option from the Dock (on GNOME) that it doesn't work. I don't know if it's related but I'm certain that is a .desktop or a DBUS fix. The URL Handler noticeably fails when using VSCode Online in GitHub (Press . in any repo in GitHub to bring up VSCode Online. Then press 'Crtl' + '~' to bring up the terminal. It should state that you can't run the terminal in VSCode Online and give you the option to continue on Desktop. If you select that option, nothing happens) and also, when you're trying to sign into plugins that require outside services (for example, GitHub CoPilot, you'll see that the authentication plugin doesn't catch redirection back from the browser window).
I started investigating this a little, and on my machine "New Window" and opening up vscode from within the browser's vscode online works: it opens vscode then vscode asks if I want to open that repository, when I click "yes" nothing happens though. I will keep on investigating about login issues
Thank you, Adel. I appreciate you taking the time to investigate this, mate. Let's make sure we're replicating the same problem. 1: Go to any github.dev link (such as: https://github.dev/gentoo/gentoo) 2: Click `github` button at the lower left 3: Select `Continue Working On` option 4: Select `Reopen on the Desktop` option That's where it breaks for me... It should open on VSCode Desktop, but it doesn't.
Okay, I am currently on LXQt (Xorg) and it didn't work: vscode didn't even open. I tried Gnome Wayland earlier and it worked at least for opening vscode, then vscode asks me for confirmation, but then it does nothing when I accept. I will try to figure out why.
FTR, this problem also affects GitPod support. It's completely as broken as Codespaces. Just thought I should add that...
Do you have some solution?
As of the last couple of months, they've actually been working alright for me.
Hello! Maybe we can close this issue for now then and people can reopen it if ever
Hello, My PR [1] added the xdg-open dependency to vscode, maybe that was the issue for the ones who didn't have it pulled by other packages. I'll mark this issue as solved by it. Feel free to reopen another bug report. [1] https://github.com/gentoo/gentoo/pull/33221
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8be7f9a0d135c06b695821abcef0b5990cdbd736 commit 8be7f9a0d135c06b695821abcef0b5990cdbd736 Author: Adel KARA SLIMANE <adel.ks@zegrapher.com> AuthorDate: 2023-10-06 21:04:45 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2023-10-07 04:54:10 +0000 app-editors/vscode: update dependencies Closes: https://bugs.gentoo.org/859406 Signed-off-by: Adel KARA SLIMANE <adel.ks@zegrapher.com> Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> .../{vscode-1.83.0.ebuild => vscode-1.83.0-r1.ebuild} | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
Why app-i18n/ibus is required?
It is in the dependencies for making the snap version of vscode. I have put all the information in the PR message https://github.com/gentoo/gentoo/pull/33221
(In reply to Adel KARA SLIMANE from comment #15) > It is in the dependencies for making the snap version of vscode. > > I have put all the information in the PR message > https://github.com/gentoo/gentoo/pull/33221 As an aside, in future, please include that information in the commit message too.
I thought it would be too long, will do. Also putting in the commit message isn't that easily findable because the commit will not appear in the blame as soon as another vscode version gets added. Maybe best to be put in comments in the ebuild itself
(In reply to Adel KARA SLIMANE from comment #17) > I thought it would be too long, will do. > > Also putting in the commit message isn't that easily findable because the > commit will not appear in the blame as soon as another vscode version gets > added. That's not a reason to not include it - if it was worth writing in the PR to begin with, it's worth putting in the commit message. (Although it would be visible in git log and such, and blame can be taught to work harder, but I get the point) > > Maybe best to be put in comments in the ebuild itself Right, sometimes it's hard to figure out if a comment is better vs commit message.
snap dependencies naturally lean heavily towards ubuntu/gnome, i think its a mistake to blindly include them here. things like ibus really are not necessary here. I hope we can revisit this.
(In reply to Gino McCarty from comment #19) > snap dependencies naturally lean heavily towards ubuntu/gnome, i think its a > mistake to blindly include them here. things like ibus really are not > necessary here. I hope we can revisit this. I'm not saying you're wrong, but it's worth keeping in mind that there's essentially 0 control over what a prebuilt binary depends on, and if it _might_ dlopen(), call a binary from, or if it has a library in its ELF NEEDED field, there's not much we can do about it. Of course, the dependencies listed in a snap might be wrong, or might not (obviously) note when something is maybe dragged in by a USE flag of a dependency instead in Gentoo, but this is an important consideration for -bins: we often end up having dependencies we don't like because anything else would be technically incorrect and unstable. But I suggest filing a new bug to discuss any issues you have, including evidence you have for the dependency being wrong.
https://bugs.gentoo.org/915380
