Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

window.restoreWindows preserve should respect window.openFilesInNewWindow #226097

Closed
WPMGPRoSToTeMa opened this issue Aug 20, 2024 · 6 comments
Closed
Labels
feature-request Request for new features or functionality workbench-window Window management

Comments

@WPMGPRoSToTeMa
Copy link

WPMGPRoSToTeMa commented Aug 20, 2024

window.openFilesInNewWindow option is ignored on session restore when window.restoreWindows is set to preserve: file is always opened in some specific restored window. --new-window command-line option is also ignored. I expect that a file should always be opened in a new window on session restore when window.openFilesInNewWindow is either default or on.

@bpasero
Copy link
Member

bpasero commented Aug 21, 2024

What are the steps to get it to not open a file?

@bpasero bpasero added the info-needed Issue requires more information from poster label Aug 21, 2024
@WPMGPRoSToTeMa
Copy link
Author

WPMGPRoSToTeMa commented Aug 21, 2024

@bpasero, sorry, looks like it was a bug in some previous version. I was not able to open an untrusted file when a trusted folder was restored. But in the latest version it works fine (asking if you want to trust it).

Still, there are two unexpected things with "window.restoreWindows": "preserve" on session restore:

  1. --new-window command-line option is ignored.
  2. window.openFilesInNewWindow setting is also ignored.

I think (1) should be treated as a bug and (2) may be treated as a feature request since it is a breaking change and a new setting value would be needed to not break the existing behavior. Should I leave this issue for (2) and open another one for (1)?

@vs-code-engineering vs-code-engineering bot removed the info-needed Issue requires more information from poster label Aug 21, 2024
@bpasero
Copy link
Member

bpasero commented Aug 23, 2024

Yes, agree on the bug: #226392

Leaving the rest here as feature request.

@bpasero bpasero added feature-request Request for new features or functionality workbench-window Window management labels Aug 23, 2024
@bpasero bpasero removed their assignment Aug 23, 2024
@bpasero bpasero added this to the Backlog Candidates milestone Aug 24, 2024
Copy link

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

Copy link

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

Copy link

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

@vs-code-engineering vs-code-engineering bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality workbench-window Window management
Projects
None yet
Development

No branches or pull requests

2 participants