Terminal: Unable to immediately start typing after starting new window from context menu

[patrikhuber]

Hi!

Please see https://github.com/Microsoft/WSL/issues/2597 and https://github.com/Microsoft/WSL/issues/3123 for a detailed description and repro for this bug, the WSL team referred this bug to this repo.

Thanks very much!

[zadjii-msft]

As mentioned in the other issues, this doesn't seem to be repro'ing internally (on 17670). If it still repro's once Insiders catch up to that build number, then it's probably going to end up being something external to the console codebase, because there's nothing we do to control that behavior.

[wkbrd]

This still repros on Insider 17666. Please note that the test case is with a distro that came from the Windows Store. Either by typing in the distro's name (e.g., ubuntu) at the Start screen or by clicking on a Start screen tile for the distro.

This test does not use cmd.exe, the "Bash on Ubuntu on Windows" start menu item (the original launcher), or by typing "bash" at the Start screen. These other methods do work.

[wkbrd]

@zadjii-msft, I have verified that this still repros on 10.0.17672.1000 (Fast ring).

Here are my repro steps (assumes that Ubuntu or openSUSE from the Windows Store are previously downloaded and run previously)

1. With no WSL windows open, click Start button
2. Type "ubuntu" or "openSUSE" (see that Trusted store app is highlighted, not "Bash on Ubuntu on Windows"). Press Enter.
3. Start typing in window (see characters show in console)
4. Right-click taskbar icon of the WSL shell
5. Left-click on name of distro in task list menu
6. Try to type in this new window (characters do not show in console)

[zadjii-msft]

I've forwarded this along to @bitcrazed to get this routed to the right team to investigate the issue.

(for the record, until someone else from msft replies with some more details, we'll just assume that this repros on every subsequent insider's build. No need to ping the thread every build :) )

[bitcrazed]

Thanks for filing this issue @patrikhuber.

I can confirm that I can repro this issue and will work with @zadjii-msft to debug and diagnose. It MAY be an issue in Sets/Tabs, but will work with that team if so.

[cheshrkat]

In case it's significant/helps - I'm getting this on Win10 10.0.16299.551 (ie, not on fast ring, this is a work-issued machine), using WSL Ubuntu installed via Store.

Happens when launching a new window from task bar (right click the running Ubuntu on the task bar, then click Ubuntu for the new window).

[bitcrazed]

Filed bug to investigate this issue: 18715554

[nicolabeghin]

any news on this??

[zadjii-msft]

@nicolabeghin Looks like the team that owns that UX is still investigating.

[DHowett-MSFT]

Just poking in: This is still sitting on the appropriate team. They haven't prioritized a fix for it, so it's not likely to make it into 19H1.
However: Based on my reading of the bug, a solid workaround would be to pin a shortcut to wsl.exe instead of the distribution launcher itself. If you've got a number of distributions installed, you can make shortcuts for specific distributions (launching, for example, wsl.exe -d Ubuntu18.04 -- get the names from wslconfig /l!)

[DHowett-MSFT]

Since this is external, and it's been around for a while, I'm going to close this tracking issue. Thanks for the report!

[patrikhuber]

@bitcrazed said to head over here to track this issue in microsoft/WSL#2597. Now that this is also "external" here, @DHowett-MSFT where/how can we track this issue? Will it be fixed at all?

As you rightly mention, this bug is still around and it's quite annoying.

[Kyrluckechuck]

Ah, just followed the microsoft/WSL#2597 rabbit hole and finally landed here as the 'real' issue.

Since this has been removed as Needs-Tag-Fix, but also as Closed, where should I actually go to follow this?

As @patrikhuber stated, I can't believe this hasn't been resolved yet!

And the workaround that @DHowett-MSFT suggested only works partially, since wsl.exe -d Ubuntu takes me to either /mnt/c/Users/<username> or /mnt/c/Windows/system32 by default depending which cmd module it gets launched from -- which is not what most would want (the linux distro home dir would be what most would consider normal (~)).

[zadjii-msft]

For the record, the internal bug tracking this issue is still open. The bug exists somewhere in the jumplist code, and the appropriate team knows about it. It just hasn't made it to their plates to actually get fixed quite yet. I'm following the internal bug, and I'll post here when it gets investigated/fixed.

[Kyrluckechuck]

Ah, okay. Would it be possible to get a ticket somewhere externally left open for this so others can track it without assuming it's being ignored? 🙂

At present, that is how it appears to many with there being no externally-facing tickets open!

[zadjii-msft]

_Are you some sort of powerful wizard?_

The internal issue was just bumped and investigated yesterday - I just reached out to the dev team to see if they can comment publicly here with their explanation :)

[sooncj]

@Kyrluckechuck try adding cd ${HOME} to the end of your .bashrc
not sure whether you have scripts that will break, but I'm using that to launch wsl.exe to ~

[Kyrluckechuck]

@sooncj Thank you for that! I had just given up on this and figured I'd have to leave it being annoying -- that had totally lapsed my mind that the .bashrc was still being evaluated!

In essence I set up the shortcut like normal (C:\Windows\System32\wsl.exe -d Ubuntu), path'd my icon to (%ProgramFiles%\WindowsApps\CanonicalGroupLimited.UbuntuonWindows_1804.2019.521.0_x64__79rhkp1fndgsc\ubuntu.exe). Finally I unpinned the real Ubuntu and replaced it with the shortcut (which I also placed in my Start Menu dir) and Bob's your Uncle, it works like a charm!

[zadjii-msft]

Looks like there was an internal PR to fix this issue in the OS last week. The fix should be available in Insiders builds in ~4 weeks.