fix: reopens files that were opened when dragging and dropping files or folders#1704
fix: reopens files that were opened when dragging and dropping files or folders#1704tarikutk wants to merge 6 commits into
Conversation
611c04f to
5d54593
Compare
5d54593 to
802bd3b
Compare
There was a problem hiding this comment.
Pull Request Overview
This PR fixes file reopening behavior when dragging and dropping files or folders in the Content Navigator. It ensures that previously opened files are reopened at their new locations after a move operation, and prevents VSCode from incorrectly opening folders as files.
Key Changes:
- Modified the
moveTohandling logic to track closed files as an array instead of a boolean - Added a new
calculateNewFileUrimethod to compute new URIs for files that were moved - Implemented logic to reopen all previously opened files after a successful move operation
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
82a3dc9 to
af2da9a
Compare
|
Hey @tarikutk . Is there a github issue associated with this PR? Or rather, what issue is this solving? |
yes @scottdover, there is a GitHub issue associated with it. I attached the link now in the PR message. it is #1478. |
|
Sorry for the delay in getting back to this one. At a high level, this is how the code is structured w/r/t file access.
Your implementation has itc ( |
8d2e0f0 to
49b6eeb
Compare
|
I updated @scottdover . |
|
the commit for itcServerAdapter is something which I was not able to test. and the last one is just to fix typescript issues. please let me know if itcServerAdapter works and if the fix for typescript breaks things. I will revert those if needed. Thanks |
49b6eeb to
e2db22e
Compare
…or folders Signed-off-by: tariku <tarikutadese24@gmail.com>
Signed-off-by: tariku <tarikutadese24@gmail.com>
Signed-off-by: tariku <tarikutadese24@gmail.com>
Signed-off-by: tariku <tarikutadese24@gmail.com>
Signed-off-by: tariku <tarikutadese24@gmail.com>
Signed-off-by: tariku <tarikutadese24@gmail.com>
scottdover
left a comment
There was a problem hiding this comment.
This is looking a lot better...just a few minor things.
| const newFileUri = this.model | ||
| .getAdapter() | ||
| .calculateNewFileUri?.(closedFileUri, item, newUri); |
There was a problem hiding this comment.
Calls to adapter methods should be contained within a ContentModel (i.e. this should be this.model.calculateNewFileUri). It doesn't look like we expose adapter in any other content data provider methods.
|
|
||
| export const extractPathFromUri = (uri: string): string => { | ||
| try { | ||
| const queryStart = uri.indexOf("?"); |
There was a problem hiding this comment.
nitpick. We're doing this indexOf query param check here and below. Creating a small shared function to handle this functionality would prevent us from repeating ourselves.
| oldBasePath: string, | ||
| closedFilePath: string, | ||
| newItemUri: Uri, | ||
| dirSeparator: string, |
There was a problem hiding this comment.
There's no need to pass this in as a parameter. The function is available to call just above this one.
| const queryStart = uri.indexOf("?"); | ||
| if (queryStart === -1) { | ||
| return ""; | ||
| } | ||
|
|
||
| const queryString = uri.substring(queryStart + 1); |
There was a problem hiding this comment.
Seeing this behavior once more...if this behavior is shared across multiple connection types, a suitable place to define a helper function may be in client/src/connection/util
| const decodedQuery = decodeURIComponent(queryMatch[1]); | ||
| const newQuery = decodedQuery.replace( | ||
| /(\/files\/[^&]*)/, | ||
| `$1~fs~${filename}`, |
There was a problem hiding this comment.
Would it be possible to use SAS_FILE_SEPARATOR here and above (you'll likely need to change that to new RegExp(...)) instead of hard coding this?
Summary:
Testing:
verified it opens previously opened files instead of opening a folder as a file.
Fixes #1478