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

[1.16+] Icons in the new tab dropdown are 🫥 #18826

New Issue
Closed
opened 2026-01-31 06:25:31 +00:00 by claunia · 20 comments
claunia commented 2026-01-31 06:25:31 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (Nov 4, 2022).

This is forked off of cfdea71dc0

image

Looks like the actual image icons are now hidden in specifically the dropdown. They're still fine in the Cmdpal, SUI, and on tabs themselves

Originally created by @zadjii-msft on GitHub (Nov 4, 2022). This is forked off of cfdea71dc08103b1f142cbb26c415ff7b1b2e529 ![image](https://user-images.githubusercontent.com/18356694/200057403-672a92f8-d975-4bf9-a36c-2bb4b5d2a480.png) Looks like the actual image icons are now hidden in specifically the dropdown. They're still fine in the Cmdpal, SUI, and on tabs themselves
claunia commented 2026-01-31 06:25:33 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 4, 2022):

wait these never worked in dev builds did they

@zadjii-msft commented on GitHub (Nov 4, 2022): wait these never worked in dev builds did they
claunia commented 2026-01-31 06:25:34 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Nov 5, 2022):

wait these never worked in dev builds did they

This is my dev build from an older commit on main:
image

@lhecker commented on GitHub (Nov 5, 2022): > wait these never worked in dev builds did they This is my dev build from an older commit on main: ![image](https://user-images.githubusercontent.com/2256941/200092839-94a14f90-d773-447b-a5f3-95ef206449d2.png)
claunia commented 2026-01-31 06:25:34 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 1, 2022):

Looking at the Visual Tree, looks like the \ones that are busted are IconSourceElement's, not ImageIcon's. Hard to use the VT though, the popup dismisses itself if you focus VS.

@zadjii-msft commented on GitHub (Dec 1, 2022): Looking at the Visual Tree, looks like the \ones that are busted are `IconSourceElement`'s, not `ImageIcon`'s. Hard to use the VT though, the popup dismisses itself if you focus VS.
claunia commented 2026-01-31 06:25:34 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 2, 2022):

what the sweet baby jesus

This only happens for me with icons from the package. Images outside the package? Good to go.

But WEIRDER - If I save the settings, then the icons all COME BACK. All of them. I don't even need to change anything, just touch settings.json.

WEIRDER YET - if another Terminal is already running, then launching another Terminal will load them just fine. Even if I do like, an unelevated, then an elevated window - the admin one has fixed icons.

@zadjii-msft commented on GitHub (Dec 2, 2022): what the sweet baby jesus This only happens for me with icons from the package. Images outside the package? Good to go. But WEIRDER - If I save the settings, then the icons all COME BACK. All of them. I don't even need to change anything, just `touch settings.json`. WEIRDER YET - if another Terminal is already running, then launching another Terminal will load them just fine. Even if I do like, an unelevated, then an elevated window - the admin one has fixed icons.
claunia commented 2026-01-31 06:25:35 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 2, 2022):

Repros on 85ca8f556c, before #14107. Maybe not blocking after all.

@zadjii-msft commented on GitHub (Dec 2, 2022): Repros on 85ca8f556c377ed301221bae95b5b9909d60cf55, before #14107. Maybe not blocking after all.
claunia commented 2026-01-31 06:25:35 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 2, 2022):

Alrighty this repros on release-1.16. This isn't any sort of regression. I bet it's something weird with the MUX on my machine.

I'll close this out unless someone else sees this in a selfhost build in the next couple weeks.

@zadjii-msft commented on GitHub (Dec 2, 2022): Alrighty this repros on `release-1.16`. This isn't any sort of regression. I bet it's something weird with the MUX on my machine. I'll close this out unless someone else sees this in a selfhost build in the next couple weeks.
claunia commented 2026-01-31 06:25:35 +00:00
Author
Owner
Copy Link

@awakecoding commented on GitHub (Dec 6, 2022):

@zadjii-msft I encountered the same issue, and just like you, the icons magically came back after editing settings.json. If only touching the file is enough, then I guess something gets initialized when WT detects the file was updated?

@awakecoding commented on GitHub (Dec 6, 2022): @zadjii-msft I encountered the same issue, and just like you, the icons magically came back after editing settings.json. If only touching the file is enough, then I guess something gets initialized when WT detects the file was updated?
claunia commented 2026-01-31 06:25:36 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 6, 2022):

Boom ^ he beat me to it

@DHowett commented on GitHub (Dec 6, 2022): Boom ^ he beat me to it
claunia commented 2026-01-31 06:25:36 +00:00
Author
Owner
Copy Link

@awakecoding commented on GitHub (Dec 6, 2022):

This issue may not be directly linked to settings.json, since the icons are gone again. This has the smell of a race condition, and fiddling with settings.json may just just be enough to get the "lucky timing":

image

@awakecoding commented on GitHub (Dec 6, 2022): This issue may not be directly linked to settings.json, since the icons are gone again. This has the smell of a race condition, and fiddling with settings.json may just just be enough to get the "lucky timing": ![image](https://user-images.githubusercontent.com/295841/206023003-48399eb9-cda8-4ceb-86ee-8fb412fba1a8.png)
claunia commented 2026-01-31 06:25:36 +00:00
Author
Owner
Copy Link

@awakecoding commented on GitHub (Dec 7, 2022):

I suspect this issue has been there for a while - I recall seeing it some time ago, but thought it was due to my inexperience with the project, and that I had somehow incorrectly built and launched it. Here's the extracted 1.15.2874.0 release MSIX package extracted locally to be launched unpackaged, showing the same invisible icon behavior:

image

Whatever it is, I really feel like it's specific to unpackaged usage. I have the exact same version of Windows Terminal installed with the MSIX and it doesn't have the issue. I'm on Windows 11 21H2, so we can rule out 22H2-related issues, if any.

@awakecoding commented on GitHub (Dec 7, 2022): I suspect this issue has been there for a while - I recall seeing it some time ago, but thought it was due to my inexperience with the project, and that I had somehow incorrectly built and launched it. Here's the extracted 1.15.2874.0 release MSIX package extracted locally to be launched unpackaged, showing the same invisible icon behavior: ![image](https://user-images.githubusercontent.com/295841/206207500-e0297d90-08b7-46e2-baa8-7f67d55eb16f.png) Whatever it is, I really feel like it's specific to unpackaged usage. I have the exact same version of Windows Terminal installed with the MSIX and it doesn't have the issue. I'm on Windows 11 21H2, so we can rule out 22H2-related issues, if any.
claunia commented 2026-01-31 06:25:37 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 7, 2022):

I really feel like it's specific to unpackaged usage

See, now I was testing with Debug Dev builds straight out of VS, and those do deploy a package, so I don't think it's exclusively that.

But it does pique my curiosity that these are all ms-appx:// images. Almost as if the packaged resource loader fails if you ask too early? Though, I feel like I would have noticed this a long time ago if it were any sort of consistent (like it seemingly is now).

If this doesn't repro on my machine with the selfhost, release, PGO'd build we throw together next week, I'm gonna punt this out of 1.17. Still a bug, but this is clearly not a recent regression.

@zadjii-msft commented on GitHub (Dec 7, 2022): > I really feel like it's specific to unpackaged usage See, now I was testing with Debug Dev builds straight out of VS, and those do deploy a package, so I don't think it's exclusively that. But it does pique my curiosity that these are all `ms-appx://` images. Almost as if the packaged resource loader fails if you ask too early? Though, I feel like I would have noticed this a long time ago if it were any sort of consistent (like it seemingly is now). If this doesn't repro on my machine with the selfhost, release, PGO'd build we throw together next week, I'm gonna punt this out of 1.17. Still a bug, but this is clearly not a recent regression.
claunia commented 2026-01-31 06:25:37 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 7, 2022):

There's one caveat actually I just remembered.

If you extract the msix using tar, 7-Zip, or Compressed Folders you get icons with names like...

ProfileIcons\%7B...

If you extract it using makeappx unpack, you get...

ProfileIcons\{...

The former won't work!
This will not apply to a local build, but it may confound the old version repros. 😄

@DHowett commented on GitHub (Dec 7, 2022): There's _one_ caveat actually I just remembered. If you extract the `msix` using `tar`, 7-Zip, or Compressed Folders you get icons with names like... ``` ProfileIcons\%7B... ``` If you extract it using `makeappx unpack`, you get... ``` ProfileIcons\{... ``` The former won't work! This will not apply to a local build, but it may confound the old version repros. :smile:
claunia commented 2026-01-31 06:25:37 +00:00
Author
Owner
Copy Link

@awakecoding commented on GitHub (Dec 7, 2022):

Indeed, I hadn't noticed this - got any idea why? Is it encoded in a weird way? I used 7-zip to easily extract the msix contents.

I did a quick and dirty fix on the file names:

Get-ChildItem *%7B* | ForEach-Object { Move-Item $_.FullName ($_.FullName -Replace '%7B','{') }
Get-ChildItem *%7D* | ForEach-Object { Move-Item $_.FullName ($_.FullName -Replace '%7D','}') }

However, the issue remains, so I guess it's something else

@awakecoding commented on GitHub (Dec 7, 2022): Indeed, I hadn't noticed this - got any idea why? Is it encoded in a weird way? I used 7-zip to easily extract the msix contents. I did a quick and dirty fix on the file names: ``` Get-ChildItem *%7B* | ForEach-Object { Move-Item $_.FullName ($_.FullName -Replace '%7B','{') } Get-ChildItem *%7D* | ForEach-Object { Move-Item $_.FullName ($_.FullName -Replace '%7D','}') } ``` However, the issue remains, so I guess it's something else
claunia commented 2026-01-31 06:25:37 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 15, 2022):

From the bug bash Preview build:

image

yikes.

@zadjii-msft commented on GitHub (Dec 15, 2022): From the bug bash Preview build: ![image](https://user-images.githubusercontent.com/18356694/207757358-00a855f2-f3c2-49a2-af43-967fd5156c18.png) yikes.
claunia commented 2026-01-31 06:25:37 +00:00
Author
Owner
Copy Link

@awakecoding commented on GitHub (Dec 15, 2022):

The profile icons are some of the few resources included as file references, not embedded data references, inside the main resources.pri. I wonder if including them as embedded data would be sufficient to work around the problem, but I'm having trouble figuring out how to control this in the current build system.

src/cascadia/CascadiaPackage/CascadiaPackage.wapproj includes src/cascadia/CascadiaResources.build.items

<Import Project="$(MSBuildThisFileDirectory)..\CascadiaResources.build.items" />

CascadiaResources.build.items defines:

<!-- Profile Icons -->
<Content Include="$(OpenConsoleDir)src\cascadia\CascadiaPackage\ProfileIcons\**\*">
  <DeploymentContent>true</DeploymentContent>
  <Link>ProfileIcons\%(RecursiveDir)%(FileName)%(Extension)</Link>
</Content>

and there's this weird thing at the end of the file:

  <!-- Reprint all content as Nones for Universal project type to include it in the resources -->
  <ItemGroup>
    <None Include="@(Content)" />
  </ItemGroup>

build/rules/CollectWildcardResources.targets is also included in the wapproj and looks relevant.

I'm having trouble finding relevant msbuild documentation for how a wapproj file works to include resources this way. The current structure appears to include everything referenced as file references, but what I'd like to try is flag the profile icons to be included as embedded data instead. Anybody has an idea how this works?

The main wapproj appears to do a lot of hackish stuff to deal with the imported resources.pri files from the dependencies, and it's hard to follow. My understanding is that msbuild automagically imports the "final" resources from the final wapproj, including the profile icons.

@awakecoding commented on GitHub (Dec 15, 2022): The profile icons are some of the few resources included as file references, not embedded data references, inside the main resources.pri. I wonder if including them as embedded data would be sufficient to work around the problem, but I'm having trouble figuring out how to control this in the current build system. [src/cascadia/CascadiaPackage/CascadiaPackage.wapproj](https://github.com/microsoft/terminal/blob/main/src/cascadia/CascadiaPackage/CascadiaPackage.wapproj) includes [src/cascadia/CascadiaResources.build.items](https://github.com/microsoft/terminal/blob/main/src/cascadia/CascadiaResources.build.items) ``` <Import Project="$(MSBuildThisFileDirectory)..\CascadiaResources.build.items" /> ``` CascadiaResources.build.items defines: ``` <!-- Profile Icons --> <Content Include="$(OpenConsoleDir)src\cascadia\CascadiaPackage\ProfileIcons\**\*"> <DeploymentContent>true</DeploymentContent> <Link>ProfileIcons\%(RecursiveDir)%(FileName)%(Extension)</Link> </Content> ``` and there's this weird thing at the end of the file: ``` <!-- Reprint all content as Nones for Universal project type to include it in the resources --> <ItemGroup> <None Include="@(Content)" /> </ItemGroup> ``` [build/rules/CollectWildcardResources.targets](https://github.com/microsoft/terminal/blob/main/build/rules/CollectWildcardResources.targets) is also included in the wapproj and looks relevant. I'm having trouble finding relevant msbuild documentation for how a wapproj file works to include resources this way. The current structure appears to include everything referenced as file references, but what I'd like to try is flag the profile icons to be included as embedded data instead. Anybody has an idea how this works? The main wapproj appears to do a lot of hackish stuff to deal with the imported resources.pri files from the dependencies, and it's hard to follow. My understanding is that msbuild automagically imports the "final" resources from the final wapproj, including the profile icons.
claunia commented 2026-01-31 06:25:38 +00:00
Author
Owner
Copy Link

@PankajBhojwani commented on GitHub (Jan 12, 2023):

Tried cleaning and rebuilding (since it seems to only happen on first launch of Terminal) on my machine and on @carlos-zamora's - and cannot seem to repro this. @zadjii-msft any ideas?

@PankajBhojwani commented on GitHub (Jan 12, 2023): Tried cleaning and rebuilding (since it seems to only happen on first launch of Terminal) on my machine and on @carlos-zamora's - and cannot seem to repro this. @zadjii-msft any ideas?
claunia commented 2026-01-31 06:25:38 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 13, 2023):

w e i r d, extra so that it also apparently doesn't repro on my slaptop, only my desktop. I wonder if this has anything to do with the busted MUX2.7 inbox on my machine. That's the only thing I can think of that's particularly different. That also seemingly shouldn't make a difference, cause we've got a sxs MUX that should work fine.

I'll spin a 1.15 build on my machine that repros this, and see what it does. If it repros even there, then I'm inclined to punt.

@zadjii-msft commented on GitHub (Jan 13, 2023): w e i r d, extra so that it also apparently doesn't repro on my slaptop, only my desktop. I _wonder_ if this has anything to do with the busted MUX2.7 inbox on my machine. That's the only thing I can think of that's particularly different. That also seemingly shouldn't make a difference, cause we've got a sxs MUX that should work fine. I'll spin a 1.15 build on my machine that repros this, and see what it does. If it repros even there, then I'm inclined to punt.
claunia commented 2026-01-31 06:25:38 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 13, 2023):

Alrighty yea this is something weird with my machine. I'm punting this out to the backlog cause I can repro this on release-1.15

@zadjii-msft commented on GitHub (Jan 13, 2023): Alrighty yea this is something weird with my machine. I'm punting this out to the backlog cause I can repro this on `release-1.15`
claunia commented 2026-01-31 06:25:38 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Mar 8, 2023):

/dup #14954

Finally figured out why this is happening! Moving over to that one!

@carlos-zamora commented on GitHub (Mar 8, 2023): /dup #14954 Finally figured out why this is happening! Moving over to that one!
claunia commented 2026-01-31 06:25:38 +00:00
Author
Owner
Copy Link

@microsoft-github-policy-service[bot] commented on GitHub (Mar 8, 2023):

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!

@microsoft-github-policy-service[bot] commented on GitHub (Mar 8, 2023): 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-UserInterface Help Wanted Issue-Bug Priority-3 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#18826
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?