Closed skylarnam closed 4 years ago
/feedback
Hi there!
Can you please send us feedback with the Feedback Hub with this issue and paste the link here so we can more easily find your crash information on the back end?
Thanks!
This is also happening for me after upgrading to the latest windows-terminal version. My monitors are all the same resolution though. I can confirm that the issue doesn't occur with multiple tabs open.
Windows build number: Microsoft Windows [Version 10.0.18362.0] Windows Terminal Version: 0.6.2951.0
Same experience on Windows 10 with 0.6.2951.0. Adding another tab is a simple work around (Thanks @skylarnam for noticing that.)
Here's the feedback info that hopefully has the details you need: https://aka.ms/AA6e2dw
Scenario #1) If I open WSL and close PowerShell, (having one tab with WSL open) then drag over it works fine. If I then open PowerShell and close WSL and drag to any monitor it works until I try dragging from my primary display onto another display.
Scenario #2) If I open Terminal, add a WSL tab, close the PowerShell tab, then open a new PowerShell tab and close WSL. Then drag from the primary display to another it crashes.
Conclusions: This only impacts dragging from the primary display when a PowerShell tab is the only open tab, but not necessarily the first open tab.
Scenario #1) If I open WSL and close PowerShell, (having one tab with WSL open) then drag over it works fine. If I then open PowerShell and close WSL and drag to any monitor it works until I try dragging from my primary display onto another display.
Scenario #2) If I open Terminal, add a WSL tab, close the PowerShell tab, then open a new PowerShell tab and close WSL. Then drag from the primary display to another it crashes.
Conclusions: This only impacts dragging from the primary display when a PowerShell tab is the only open tab, but not necessarily the first open tab.
Seeing this behavior as well. My default start behavior is to open a WSL session which will die upon letting go of the mouse click after dragging the terminal window to any other monitor. If I have cmd as my first tab then drag+drop works fine. Its clearly dying when letting go of the click, not on the drag.
Hi, I just sent a feedback using the Feedback Hub. Thanks everyone for more details.
It has nothing to do with the drag ... the same crash behaviour is exhibited if you use the windows + arrow keys
Nasty bug... thanks for the workaround with the two tabs!
For me the multiple tabs work around only works if one of the tabs is CMD
edit: Also noticed it's only when moving from my laptop screen(4k) to an external monitor(1080p). Moving between my external monitors seems fine. Maybe due to them using different graphic cards?
It has nothing to do with the drag ... the same crash behaviour is exhibited if you use the windows + arrow keys
which is 100% what I said.
I have open the #3376 bu it's same issue, just I add : when it's on the same Graphic card, it's ok (4K to 1080p ok), but not when I drag and drop from screen on my external card to a screen on my internal card. Same workaround, it's ok with 2 tabs.
Just hit this bug. The multiple tabs with cmd workaround is the only thing that works for me.
Based off some other issues, this may or may not be related to #2277.
I've certainly been having some difficulty repro'ing this, though this is hitting a good number of people. If someone who can repro this consistently could help debug, that'd be much appreciated :)
I can consistently reproduce it when I set Ubuntu-18.04 as the default profile, it does not happen when openning Windows PowerShell or cmd.
Then I also have to quickly drag Terminal to another monitor, while it is still loading Ubuntu, if I wait a few seconds for the command prompt to be ready, then I can safely move Terminal to another monitor without it crashing.
Similar here -- it happens when I drag while the script setting up my development environment is running. If I wait for it to finish then it is safe to move. In my case it is PowerShell-based profile. I can provide a dump on Microsoft-internal share.
Woah holy crap, that does it. Thanks @Julien-Marcou!
Okay so it's even more challenging that just dragging it to another display while it's starting up. It specifically crashes if the title is changing when you drag it to the other display. I'm not sure if it has to change exactly during the drag, or how it's related, but now that I have a little script repros this consistently, I can investigate more.
Yes, I think this started to happen for me when I set the ubuntu 18.04 terminal as default, so that's a good thing to check.
Unlike a few of the recent comments, as just a heads-up, I get consistent repros w/o having Ubuntu set up as my default profile. I have powershell and cmd as my profiles and the first is my default one.
Update:
I wrote a little script that changes the title every .25s. If you moved the Terminal window across a DPI border while it was running, it would almost instantly crash into the debugger. However, I had a hypothesis why it was so hard to get this to repro earlier today. I did a quick git bisect to find out why:
master
, fee3fdfSo it looks like #3394 actually fixes this bug too. Thanks @greg904!
@zadjii-msft I think I found a way to reproduce the crash even in master
(or maybe it's another bug?):
There is no crash when multiple tabs are opened.
Also, I don't know if it's related but when it moves from one monitor to another it prints this in the output in Visual Studio:
onecoreuap\windows\wgi\winrt\display\displaycommon.cpp(411)\Windows.Graphics.dll!00007FFF221904B0: (caller: 00007FFF2219017A) ReturnHr(22) tid(19f0) 80070490 Element not found.
onecoreuap\windows\wgi\winrt\display\displaycommon.cpp(411)\Windows.Graphics.dll!00007FFF221904B0: (caller: 00007FFF221901F5) ReturnHr(23) tid(19f0) 80070490 Element not found.
@greg904 oh no
I can't get it to repro with those steps at all ;__;
I definitely see the blurriness you're talking about, but I don't get the crash to happen with the same setup.
The logging there is a message I've seen plenty of before - usually it's not fatal, but I never really knew what was causing it.
@zadjii-msft It looks like it depends on the title of the default profile. When I set it to "aaaaaaaaaaaaa" it crashes but with just "aaa" or "aaaaaaaaaaaaaaaaaaaaaaaaaa" it doesn't (I tried multiple times for each one and it seems consistent). Also with the default config ("Windows PowerShell") it crashes.
aaaaaaaaaaaaa
welp. That's insane, but it works. I'll dig in farther in the morning.
Hokay. So, the problematic line of code here is L48 in TitleBarControl.cpp
Looks like that MaxWidth
call is causing a change in some other element of the application, which is then eventually causing the TitlebarControl's root to change size again. Here, ContentRoot
is hosting the TabRowControl
, which is mostly just a wrapper for the TabView
.
That code exists to make sure that that tab row doesn't push the caption buttons off the side of the window. Without it, this doesn't repro anymore. However, this happens:
The "X" has been pushed off the window, and the drag region is partially obscuring the last tab.
So I'll either need to find a way to:
MaxWidth
call.I actually have already done a PR that does this: #3347 (but I need to fix the merge conflicts and I found a bug with it so I need to fix it).
However I'm not sure if that it fixed the root cause of the crash because the PR patches the crash with the repro I posted just before but I found yet another repro to crash that isn't fixed by the PR:
@greg904 haha, I literally just finished merging master into that PR to see if it would be a silver bullet to fix this crash. It unfortunately wasn't.
I've also tried a branch where I replace the Grid
in the TabRowControl
with a RelativePanel
, and shockingly that also repros this crash. I'm starting to think that the MaxWidth
call wasn't the real problem here, and there's something else going on.
I might let this sit for a day. I think I've gotten to close to the problem, I might need to take a step back and come at it another direction. Feel free to take a look in the meantime 😜
I don't know if that helps but when I set the visibility of the mux:TabView
to collapsed or when I force its size to say 400 width and 50 height there is no crash. Maybe it's the mux:TabView
resize that causes the bug? Here is what is called on resize: https://github.com/microsoft/microsoft-ui-xaml/blob/25acf5b783d2b93a8f52cb24569d68fd26dbda57/dev/TabView/TabView.cpp#L526
I don't how VS enough to put a breakpoint here though.
I can also confirm this bug. My steps to reproduce:
System: Windows 10 1909 build 18363.449 Terminal: 0.6.2951.0
Hello! Same for me. But I even not dragging terminal to another display. I just connect external display as primary and terminal crash immediately :(
One more here. Nearly opened a duplicate. I'm sure my home setup doesn't have this problem (200% scale on the primary monitor) but hit it in my office set up (125% scale). And stumbled on the 2 panes solution as well. Initially I thought the solution need cmd to be the second pane, but any 2 panes seem to be OK. Happy to provide extra debug info if it helps, but looks like the cause has been found. Just keen to a fix in the next update.
One more here. Nearly opened a duplicate. I'm sure my home setup doesn't have this problem (200% scale on the primary monitor) but hit it in my office set up (125% scale). And stumbled on the 2 panes solution as well. Initially I thought the solution need cmd to be the second pane, but any 2 panes seem to be OK. Happy to provide extra debug info if it helps, but looks like the cause has been found. Just keen to a fix in the next update.
For my setup (4k@125% and wqhd @100%) PowerShell is the default shell. With only PowerShell I can move from 4K to other monitor. As soon as i open the anaconda shell as the second tab it crashes when I move. With only one tab this does not happen. Very strange
I'm having the same issue on my setup. Two tabs workaround doesn't help.
Primary monitor is 2K at 125% and other monitors are 1080p at 100%. The app crashes as soon as I move it from the primary monitor to the others.
FWIW, dragging works for me using a single tab if that tab is running a program. For example, when I run npm start
to start a local webserver I can then drag the window (and use cmd + [arrow key]
).
My notes: Win-Shift-Left and Win-Shift-Right work fine, its just when "dragging" the window.
I'm hitting the exact same issue on 2 monitors, but for me it crashes on startup no matter what.
Specifically it's crashing at the exact same fault offset mentioned in https://github.com/microsoft/terminal/issues/3539, which I see was marked as a dupe of this issue. This occurs on a clean profile too.
Windows 1.0.1910.3002, any recent terminal version. FWIW in my normal profile the default shell is a WSL2 Ubuntu installation, if that matters.
I hope I am not muddying the waters here, but my issues looks like it could possibly be related.
I just switched from a dual monitor setup (2 x 27" @ 1080p with 100% scaling) to a single monitor (32" @ 4k with 125% scaling) and now if I open terminal it opens the window and then crashes straight away. So I am not actually moving a working terminal window to a different display, but rather launching it into a different display environment with the result being that it crashes immediately.
@T313C0mun1s7 I think it is because terminal remembered the last postition and tried to restore to original possition , then got crushed . Looks like a new problem .
I saw such behavious on some other programs , though them were usually unreachable(invisible) instead of crash . Moreover, if you are using displayfustion or some else dual taskbar/monitor softwares, they may be the problem too.
Hey everyone, just an update here:
I've dug real deep into XAML over the last week, and working with @teap, we were able to find that the source of the E_LAYOUTCYCLE
wasn't coming from the Windows Terminal code, it was coming from the TabView
code itself. Fortunately, @teap has whipped up a fix for us, which should be available on the next update of Microsoft.UI.Xaml
🎉.
At the time of writing it's unclear when we'll ingest that update and push an update to the store. We'll keep you posted in this thread when we know more. Thanks all for help with getting repro steps found!
Same problem here. Multiple tabs workaround only works if one of the tabs is CMD.
Happens to me as well, also when I'm dragging to a monitor with a bigger resolution (tested with 1080p to 1440p), maybe the problem's not with the dragging to another monitor alone but happens when I'm dragging to the left or right side of the screen (similar to WIN+L or WIN+R shortcuts) like I normally do with my windows.
Thanks,
Simone.
:tada:This issue was addressed in #3832, which has now been successfully released as Windows Terminal Preview v0.7.3382.0
.:tada:
Handy links:
For what it's worth, your amusing release notes keep me coming back. Thanks for the hard work.
@JustinGrote thanks 😁
Environment
Steps to reproduce
Expected behavior
Terminal is dragged onto another monitor
Actual behavior
It crashes. Funny thing: The terminal doesn't crash when I have more than one tab open.