skylarnam commented 5 years ago

Environment

Windows build number:  Microsoft Windows [Version 10.0.18362.418]
Windows Terminal version (if applicable): 0.6.2951.0

Steps to reproduce

Open Windows Terminal with "only one tab open"
Drag to another monitor with a lower resolution (from 2160p to 1080p)

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.

DHowett-MSFT commented 5 years ago

/feedback

ghost commented 5 years ago

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!

9jaGuy commented 5 years ago

https://aka.ms/AA6eg31

aaroneuph commented 5 years ago

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

flickerfly commented 5 years ago

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

flickerfly commented 5 years ago

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.

CosmicCatnap commented 5 years ago

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.

skylarnam commented 5 years ago

Hi, I just sent a feedback using the Feedback Hub. Thanks everyone for more details.

https://aka.ms/AA6e9sl

waltiam commented 5 years ago

It has nothing to do with the drag ... the same crash behaviour is exhibited if you use the windows + arrow keys

decstewartje commented 5 years ago

Nasty bug... thanks for the workaround with the two tabs!

winstonhenke commented 4 years ago

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?

CosmicCatnap commented 4 years ago

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.

lbalmont commented 4 years ago

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.

adrianmoya commented 4 years ago

Just hit this bug. The multiple tabs with cmd workaround is the only thing that works for me.

zadjii-msft commented 4 years ago

Based off some other issues, this may or may not be related to #2277.

zadjii-msft commented 4 years ago

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 :)

Julien-Marcou commented 4 years ago

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.

LukaszMendakiewicz commented 4 years ago

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.

zadjii-msft commented 4 years ago

Woah holy crap, that does it. Thanks @Julien-Marcou!

zadjii-msft commented 4 years ago

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.

adrianmoya commented 4 years ago

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.

skylarnam commented 4 years ago

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.

zadjii-msft commented 4 years ago

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:

✔ This crash doesn't repro in master, fee3fdf
❌ This crash repros in 0.6, d6790c0
❌ This crash repros in 6f36f8b
✔ This crash doesn't repro in 5dfc021 🎉

So it looks like #3394 actually fixes this bug too. Thanks @greg904!

beviu commented 4 years ago

@zadjii-msft I think I found a way to reproduce the crash even in master (or maybe it's another bug?):

have primary monitor with 100% scaling and second monitor with 150% scaling
open terminal (it opens in primary monitor)
move it to the second monitor
notice how the min/max/close buttons are blurry (already weird)
put your mouse cursor over the min/max/close buttons and notice how they become sharp again
move the terminal back to the primary monitor
notice how the min/max/close buttons are blurry
put your mouse cursor over the min/max/close buttons and the terminal crashes

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.

zadjii-msft commented 4 years ago

@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.

beviu commented 4 years ago

@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.

zadjii-msft commented 4 years ago

aaaaaaaaaaaaa

welp. That's insane, but it works. I'll dig in farther in the morning.

zadjii-msft commented 4 years ago

Hokay. So, the problematic line of code here is L48 in TitleBarControl.cpp

https://github.com/microsoft/terminal/blob/357e835f5d37492812e33eac1dd995232c19de63/src/cascadia/TerminalApp/TitlebarControl.cpp#L37-L50

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:

Find way to not have the tab row push the caption buttons off the side of the window
prevent the layout cycle caused by that MaxWidth call.

beviu commented 4 years ago

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:

have primary monitor with 100% scaling and second monitor with 150% scaling
open terminal with default config (it opens in primary monitor)
move it to the second monitor
click on the maximize button
click on the restore button
move the terminal back to the primary monitor
notice how the min/max/close buttons are blurry
put your mouse cursor over the min/max/close buttons and the terminal crashes

zadjii-msft commented 4 years ago

@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 😜

beviu commented 4 years ago

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.

vsalvino commented 4 years ago

I can also confirm this bug. My steps to reproduce:

System: Windows 10 1909 build 18363.449 Terminal: 0.6.2951.0

Display 1 is laptop, 1920x1080 14" with 150% scaling.
Display 2 is external monitor (HDMI), 1920x1080 24" with 100% scaling.
Terminal opens on Display 1.
When dragging to Display 2, it does not immediately crash, but trying to initiate text input causes it to crash. The problem seems to come when it needs to redraw the contents of the window.

dkryaklin commented 4 years ago

Hello! Same for me. But I even not dragging terminal to another display. I just connect external display as primary and terminal crash immediately :(

jhoneill commented 4 years ago

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.

sotsoguk commented 4 years ago

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

CoskunSunali commented 4 years ago

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.

amkoehler commented 4 years ago

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]).

JustinGrote commented 4 years ago

My notes: Win-Shift-Left and Win-Shift-Right work fine, its just when "dragging" the window.

dansanduleac commented 4 years ago

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.

https://aka.ms/AA6kfpy

T313C0mun1s7 commented 4 years ago

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.

eromoe commented 4 years ago

@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.

zadjii-msft commented 4 years ago

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!

IlanVivanco commented 4 years ago

Same problem here. Multiple tabs workaround only works if one of the tabs is CMD.

simmessa commented 4 years ago

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.

ghost commented 4 years ago

:tada:This issue was addressed in #3832, which has now been successfully released as Windows Terminal Preview v0.7.3382.0.:tada:

Handy links:

JustinGrote commented 4 years ago

For what it's worth, your amusing release notes keep me coming back. Thanks for the hard work.

DHowett-MSFT commented 4 years ago

@JustinGrote thanks 😁

microsoft / terminal

Terminal crashes when dragged to another monitor #3303

Environment

Steps to reproduce

Expected behavior

Actual behavior