recent_projects: Fix remote workspace activation - #59093
Closed
clarkenciel wants to merge 3 commits into
Closed
Conversation
|
We require contributors to sign our Contributor License Agreement, and we don't have @clarkenciel on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'. |
zed-community-bot
Bot
added
the
first contribution
clarkenciel
marked this pull request as draft
June 11, 2026 03:19
Contributor
Author
|
@cla-bot check |
cla-bot
Bot
added
the
cla-signed
|
The cla-bot has been summoned, and re-checked this pull request! |
Contributor
Author
|
A demonstration of the bug: and a demonstration of zed with my patch: NB: in the fix video the popover flickers. that is unrelated to my patch: my mouse's primary button is a bit on the fritz at the moment. |
clarkenciel
marked this pull request as ready for review
June 11, 2026 03:51
ChristopherBiscardi
added
the
area:workspace
clarkenciel
force-pushed
the
fix-58646-wsl-recent-projects
branch
from
June 12, 2026 03:34
517e60a to
b0dcda3
Compare
Veykril
self-requested a review
June 12, 2026 05:52
clarkenciel
force-pushed
the
fix-58646-wsl-recent-projects
branch
from
June 13, 2026 18:10
b0dcda3 to
9ff8372
Compare
Fixes zed-industries#58646. Workspace reactivation in the recent projects popover didn't handle remote workspaces correctly in a fresh zed window. Rather than activating the remote workspace, it would open a user's home directory with a single editor titled after the remote workspace's directory. E.g. rather than opening `my_project` in WSL2, it would open `~` with a single editor called `my_project`. Notably, the threads manager in the sidebar handles this correctly and so this fix essentially ports `Sidebar::open_workspace_for_group` to `RecentProjects::confirm`. There is probably some work worth doing to factor out this code and use it in both places, but that feels big enough to defer to another change. The key to reproduction is to use a fresh zed window that has recently opened projects. In this case the `MultiWorkspace::last_active_workspace_for_group` lookup on L1159 will return `None`. This will cause zed to fall through to the `MultiWorkspace::find_or_create_local_workspace` call on L1173. Because the selected workspace is a remote workspace, many of the checks in `MultiWorkspace::find_or_create_local_workspace_with_source_workspace` fail and we bottom out in `multi_workspace.rs:L1421` where a new, empty local workspace is created.
clarkenciel
force-pushed
the
fix-58646-wsl-recent-projects
branch
from
June 13, 2026 18:15
9ff8372 to
7b9a312
Compare
Contributor
Author
|
Closing since it looks like #59272 does the same. |
Member
|
Ah so sorry, for not getting to this first 🙇 but thank you so much for looking into this either way! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Workspace reactivation in the recent projects popover didn't handle
remote workspaces correctly in a fresh zed window. Rather than
activating the remote workspace, it would open a user's home directory
with a single editor titled after the remote workspace's directory.
E.g. rather than opening
my_projectin WSL2, it would open~witha single editor called
my_project.Notably, the threads manager in the sidebar handles this correctly and
so this fix essentially ports
Sidebar::open_workspace_for_grouptoRecentProjects::confirm. There is probably some work worth doingto factor out this code and use it in both places, but that feels
big enough to defer to another change.
The key to reproduction is to use a fresh zed window that has recently
opened projects. In this case the
MultiWorkspace::last_active_workspace_for_grouplookup on L1159 willreturn
None. This will cause zed to fall through to theMultiWorkspace::find_or_create_local_workspacecall on L1173. Becausethe selected workspace is a remote workspace, many of the checks in
MultiWorkspace::find_or_create_local_workspace_with_source_workspacefail and we bottom out in
multi_workspace.rs:L1421where a new, emptylocal workspace is created.
Self-Review Checklist:
Closes #58646
Release Notes: