-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clicking in a non-terminal control area should not steal focus from the terminal control #528
Comments
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. |
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. |
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" 🤨 |
@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. |
@Talvish not sure why it matters how wide the text is. It doesn't seem to matter to my browsers... |
@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. |
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! |
Version: 1.12.10982.0 |
@virgoparna This particular version of this bug has been fixed for a couple years now - if you're still seeing this on a new version, then I'm guessing that it's a new variation on this bug and should get a new issue opened to track it. Thanks! |
ver
at a Windows Command Prompt)18.0.18362.53
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.
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.
The text was updated successfully, but these errors were encountered: