starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Add option to disable the jumplist #12714

New Issue
Closed
opened 2026-01-31 03:22:52 +00:00 by claunia · 8 comments
claunia commented 2026-01-31 03:22:52 +00:00
Owner
Copy Link

Originally created by @WSLUser on GitHub (Feb 24, 2021).

Description of the new feature/enhancement

If a user doesn't use the jumplist, provide the option to disable it. This will happen most when you are running Terminal as Administrator. By providing this option, the ability to launch Terminal will speed up as it does require loading of the profiles into a jumplist (there is a noticeable lag that has been there ever since jump list were added compared to no jumplist.)

Proposed technical implementation details (optional)

When the Application State: https://github.com/microsoft/terminal/pull/8771 is available, that should be used to ask if a user wants to generate the jumplist or not as well as an option to change that answer. In the meantime, provide a setting in settings.json and Settings UI to disable the jumplist.

Originally created by @WSLUser on GitHub (Feb 24, 2021). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement If a user doesn't use the jumplist, provide the option to disable it. This will happen most when you are running Terminal as Administrator. By providing this option, the ability to launch Terminal will speed up as it does require loading of the profiles into a jumplist (there is a noticeable lag that has been there ever since jump list were added compared to no jumplist.) <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> # Proposed technical implementation details (optional) When the Application State: https://github.com/microsoft/terminal/pull/8771 is available, that should be used to ask if a user wants to generate the jumplist or not as well as an option to change that answer. In the meantime, provide a setting in settings.json and Settings UI to disable the jumplist. <!-- A clear and concise description of what you want to happen. -->
claunia added the Issue-TaskResolution-DuplicateProduct-TerminalArea-Performance labels 2026-01-31 03:22:52 +00:00
claunia commented 2026-01-31 03:22:53 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 24, 2021):

Do you have any data to back up the claim that the Jumplist is the thing slowing down startup? I believe since 1.5, the jumplist creation has been on a background thread (#7978):

95f63a9100/src/cascadia/TerminalApp/Jumplist.cpp (L121-L130)

So that shouldn't be slowing down the startup speed.

This will happen most when you are running Terminal as Administrator

Could you elaborate on what you mean here? Do admins not want the jumplist? The "Run as administrator" option definitely still exists, so I'm confused what you mean here.
image

@zadjii-msft commented on GitHub (Feb 24, 2021): Do you have any data to back up the claim that the Jumplist is the thing slowing down startup? I believe since 1.5, the jumplist creation has been on a background thread (#7978): https://github.com/microsoft/terminal/blob/95f63a9100c35b7fcbae535aac415671f63da4ab/src/cascadia/TerminalApp/Jumplist.cpp#L121-L130 So that shouldn't be slowing down the startup speed. > This will happen most when you are running Terminal as Administrator Could you elaborate on what you mean here? Do admins not want the jumplist? The "Run as administrator" option definitely still exists, so I'm confused what you mean here. ![image](https://user-images.githubusercontent.com/18356694/109041130-551af700-7694-11eb-80b2-7eb71fec05dd.png)
claunia commented 2026-01-31 03:22:54 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Feb 25, 2021):

I have a VM with limited resources available. More often than not, attempting to re-launch Windows Terminal when wanting to runas Administrator has a noticeable lag trying to populate the jump list. Switching to the background thread had helped considerably but I don't use the jumplist normally. I usually use the commandline mode if I wanted to run an unelevated Terminal window (looking forward to when it can be a tab instead). Task Manager doesn't seem to show much in the way of resources so I'm guessing it's a software and/or OS limitation. I just think the easiest thing to do here is simply allow a user to disable it and if they want it back, then they can re-enable it.

@WSLUser commented on GitHub (Feb 25, 2021): I have a VM with limited resources available. More often than not, attempting to re-launch Windows Terminal when wanting to runas Administrator has a noticeable lag trying to populate the jump list. Switching to the background thread had helped considerably but I don't use the jumplist normally. I usually use the commandline mode if I wanted to run an unelevated Terminal window (looking forward to when it can be a tab instead). Task Manager doesn't seem to show much in the way of resources so I'm guessing it's a software and/or OS limitation. I just think the easiest thing to do here is simply allow a user to disable it and if they want it back, then they can re-enable it.
claunia commented 2026-01-31 03:22:54 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 25, 2021):

That still just sounds like conjecture though.

  • Does running unelevated not experience the same lag on launch?
  • What specifically makes you think that the jumplist is to blame for the startup lag? Have you done any profiling/tracing to point at the jumplist as a hot path? Built a release version of the Terminal without the jumplist to compare launch timing with vs without? Or is it possible that the launch lag started around the same time as the jumplist was added, and you're not sure that the jumplist is definitely the cause, but it could be?

I'm all for customizability, but I want to make sure we have the priorities straight. There's a big difference between "I want to disable the jumplist because it's definitely responsible for noticeable lag on launch" vs "I want to disable the jumplist because I don't care for it".

@zadjii-msft commented on GitHub (Feb 25, 2021): That still just sounds like conjecture though. * Does running unelevated not experience the same lag on launch? * What specifically makes you think that the jumplist is to blame for the startup lag? Have you done any profiling/tracing to point at the jumplist as a hot path? Built a release version of the Terminal without the jumplist to compare launch timing with vs without? Or is it possible that the launch lag started around the same time as the jumplist was added, and you're not sure that the jumplist is definitely the cause, but it could be? I'm all for customizability, but I want to make sure we have the priorities straight. There's a big difference between "I want to disable the jumplist because it's definitely responsible for noticeable lag on launch" vs "I want to disable the jumplist because I don't care for it".
claunia commented 2026-01-31 03:22:55 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Mar 1, 2021):

So I would say it's a mix of both. Running elevated or not makes no difference. I launch Windows Terminal from the taskbar and right click on it. That right click is what is consuming some resources. I suspect there's something else in the background causing perf to go down (as other applications also can be noticeably slowed by unexplained resource usage) and the generation of the jump list is slowed by a couple seconds as a result. I'm not sure if there's much in the way of optimization left for the jump list. I will note that the explorer menu option doesn't lag at all. Only sometimes the File Explorer itself can lag in opening a window.

@WSLUser commented on GitHub (Mar 1, 2021): So I would say it's a mix of both. Running elevated or not makes no difference. I launch Windows Terminal from the taskbar and right click on it. That right click is what is consuming some resources. I suspect there's something else in the background causing perf to go down (as other applications also can be noticeably slowed by unexplained resource usage) and the generation of the jump list is slowed by a couple seconds as a result. I'm not sure if there's much in the way of optimization left for the jump list. I will note that the explorer menu option doesn't lag at all. Only sometimes the File Explorer itself can lag in opening a window.
claunia commented 2026-01-31 03:22:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 1, 2021):

Running elevated or not makes no difference.

Great, then we can leave it out of this discussion

I launch Windows Terminal from the taskbar and right click on it. That right click is what is consuming some resources.

Oh, so it's not the creation of the Terminal window itself that's slow, and it's not the initialization of the Jumplist entries by the Terminal. What you're referencing is the actual display of the jumplist by the windows shell itself. Can we compare with some other apps that have custom jumplists? explorer.exe probably isn't a great example (since it's going to be the same process as the taskbar itself - explorer has probably already loaded that jumplist). What about Word, or Teams? Onenote? Edge? Firefox?

Does the slowdown occur only the first time you right click on the taskbar entry, or is it on all right-clicks?

@zadjii-msft commented on GitHub (Mar 1, 2021): > Running elevated or not makes no difference. Great, then we can leave it out of this discussion > I launch Windows Terminal from the taskbar and right click on it. That right click is what is consuming some resources. Oh, so it's not the _creation of the Terminal window itself_ that's slow, and it's not the initialization of the Jumplist entries by the Terminal. What you're referencing is the actual display of the jumplist by the windows shell itself. Can we compare with some other apps that have custom jumplists? `explorer.exe` probably isn't a great example (since it's going to be the same process as the taskbar itself - explorer has probably already loaded that jumplist). What about Word, or Teams? Onenote? Edge? Firefox? Does the slowdown occur only the first time you right click on the taskbar entry, or is it on all right-clicks?
claunia commented 2026-01-31 03:22:55 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Mar 2, 2021):

So I don't have too many apps I use, especially with the jump list. With Edge (I use Edge Dev), the jumplist display is the same as Windows Terminal. When I first launched an unelevated VSCode, the first time getting the jump list to display took about 3 to 5 seconds and the second time was the same as Windows Terminal and Edge. It seems that when the system is not experiencing heavy resource usage, the first time display of the jumplist is what actually is slow and appears that the pixels or whatever are cached for the next time, speeding up the display of the jumplists. Also Word 2013 (yeah I'm aware my shop should be using something newer) doesn't experience the lag for first time startup. On my personal laptop, the Word that comes with Office 365 does always have a lag for both the jump list and the opening of it (I've always felt that Office has become more and more bloated with each new version even as new features are added and is in need of some serious perf optimizations but that's unrelated to this issue).

@WSLUser commented on GitHub (Mar 2, 2021): So I don't have too many apps I use, especially with the jump list. With Edge (I use Edge Dev), the jumplist display is the same as Windows Terminal. When I first launched an unelevated VSCode, the first time getting the jump list to display took about 3 to 5 seconds and the second time was the same as Windows Terminal and Edge. It seems that when the system is not experiencing heavy resource usage, the first time display of the jumplist is what actually is slow and appears that the pixels or whatever are cached for the next time, speeding up the display of the jumplists. Also Word 2013 (yeah I'm aware my shop should be using something newer) doesn't experience the lag for first time startup. On my personal laptop, the Word that comes with Office 365 does always have a lag for both the jump list and the opening of it (I've always felt that Office has become more and more bloated with each new version even as new features are added and is in need of some serious perf optimizations but that's unrelated to this issue).
claunia commented 2026-01-31 03:22:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 29, 2021):

Oh look this is /dup #7712

@zadjii-msft commented on GitHub (Mar 29, 2021): Oh look this is /dup #7712
claunia commented 2026-01-31 03:22:56 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 29, 2021):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Mar 29, 2021): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Performance Issue-Task Product-Terminal Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#12714
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?