Terminal: Clicking in a non-terminal control area should not steal focus from the terminal control

[oising]

• Your Windows build number: (Type ver at a Windows Command Prompt)

18.0.18362.53

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

1) start terminal
2) hit ctrl+t to bring up tabs
3) click in the space between second tab and "+" and attempt to drag window
4) window won't drag, but now input is blocked
5) right click in window area
6) input is now unblocked.

This is unlikely to occur when the tabs are NOT inlined with the title bar. It is _very_ likely to happen when tabs ARE inlined, as the free space seems like empty title bar area.

• What's wrong / what should be happening instead:

Either allow window dragging from tabs bar (when inlined), or don't allow window dragging but don't lock up input. Maybe a prompt or tooltip text might help guide the user if dragging is disabled from this area.

[zadjii-msft]

Well that certainly shouldn't be happening.

The part of the tab bar without tabs definitely shouldn't steal focus, so that's certainly a bug.

When the tabs are in the titlebar, that area _should_ be able to drag the window around, but unfortunately there's an existing bug with XAML Islands that prevents that from working.

I'll use this issue to primarily track the first problem, as the second is an external issue.

[rbeesley]

I don't know if this should be a new bug, but it is certainly related to this. I went spelunking for this specific bug, so I'll leave a comment here and then file a new one. When you open Terminal on a screen with standard DPI, the gap between the drop down and the minimize is small, so your dragable surface is small. When you move Terminal to a monitor with an HDPI / 150% scale, that gap goes away entirely and you have to use the small gap between the client area and the minimize button... since you can't use the empty space to drag the terminal. Resolving #528 will mostly solve the problem I'm filing, but I think there is an issue with how the controls are rendered on different scaled monitors.

[Jaykul]

Side note: on some of those other Windows Apps ... (like Edge) they make the new tab buttons stick right to the right side of the visible tab, so anything to the right of _that_ is dragable. ❤

Also, they _make all the tabs the same width_ so you don't get the whole window taken up when all you have is a couple of PowerShell instances ... but they show up as "C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe" 🤨

[Talvish]

@Jaykul I'm with you on the making the '+' bind to the right of the tabs (need more drag space). Same width is a bit tougher since you have an option to set the title to be the directory you are in, so can see this as optional.

Update: Just read #56 which refers to #929 ... looks like the draggable space is being addressed.

[Poopooracoocoo]

In addition to tooltips, the active tab could be full width. I'm not sure about hover.

@jaykul @talvish

[Jaykul]

@Talvish not sure why it matters how wide the text is. It doesn't seem to matter to my browsers...

[rbeesley]

@Jaykul looking at my browser right now, if I had as many tabs open in Terminal, every one would say "C:\Wind," and that's about it. To fix this, we really need big-endian directory structures: "System32\Windows\C:" (or is that little?), or maybe we need to start reading RTL. I think this ship may have sailed. Maybe justify the directory name on the working directory, so you'd see something like C:\Windows\[Syste]m32, where the part in the square brackets is the part which is windowed on the tab when it gets small.

[DHowett-MSFT]

I think we've gotten rid of a bunch of ways this might have happened, so I'm gonna close this out for now. Thanks for playing!