Skip to content
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

Info bar obscures tab bar #11606

Closed
KalleOlaviNiemitalo opened this issue Oct 25, 2021 · 3 comments · Fixed by #11609
Closed

Info bar obscures tab bar #11606

KalleOlaviNiemitalo opened this issue Oct 25, 2021 · 3 comments · Fixed by #11609
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@KalleOlaviNiemitalo
Copy link

KalleOlaviNiemitalo commented Oct 25, 2021

Windows Terminal version (or Windows build number)

1.12.2931.0

Other Software

No response

Steps to reproduce

  1. Configure Settings - Appearance like this:
    • Always show tabs: On
    • Hide the title bar (requires relaunch): Off
    • Show acrylic in tab row (requires relaunch): Off
  2. Configure the Command Prompt profile like this:
    • Profile termination behavior: Close only when process exits successfully
  3. Restart Windows Terminal Preview.
  4. Open three tabs with the Command Prompt profile, and close the tab with the default profile.
  5. Type EXIT 1 and press Enter.

Expected Behavior

The title bar, the CloseOnExitInfoBar, and the tab bar are all visible.

Actual Behavior

The title bar and the CloseOnExitInfoBar are visible. The tab bar is not visible, but the Ctrl+Tab key combination still switches between tabs.

image

Related to #10798.

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Oct 25, 2021
@zadjii-msft
Copy link
Member

Boy it sure does. You can tell how many members of the dev team have "show tabs in titlebar" disabled 😝

@zadjii-msft zadjii-msft added Area-User Interface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Issue-Bug It either shouldn't be doing this or needs an investigation. labels Oct 25, 2021
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Oct 25, 2021
@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone Oct 25, 2021
zadjii-msft added a commit that referenced this issue Oct 25, 2021
  Fixes #11606

  This is weird, but the infobars would appear totally on top of the
  TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar
  obscuring the tabs.

  Now, the infobars are strictly inserted after the tabs, before the content. So
  when they appear, they will reduce the amount of space usable for the control.
  That is a little annoying, but preferable to the tabs totally not existing.

  Relevant conversation notes from #10798:

  > > If the info bar is not local to the tab, then its location between the tab
  > > bar (when the title bar is hidden) and the terminal panes feels
  > > misleading. Should it instead be above the tab bar or below the terminal
  > > panes?
  >
  > You're... not wrong here. It's maybe not the best place for it, but _on top_
  > of the tabs would look insane, and probably wouldn't even work easily, given
  > the way we reparent the tab row into the titlebar.
  >
  > In the pane itself would make more sense, but that runs abreast of all sorts
  > of things like #9024, #4998, which might make more sense.

  I'm just gonna go with this now, because it's _better_ than before, while we
  work out what's _best_.
@ghost ghost added the In-PR This issue has a related PR label Oct 25, 2021
@ghost ghost closed this as completed in #11609 Oct 26, 2021
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Oct 26, 2021
ghost pushed a commit that referenced this issue Oct 26, 2021
…of (#11609)

Fixes #11606

This is weird, but the infobars would appear totally on top of the
TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar
obscuring the tabs.

Now, the infobars are strictly inserted after the tabs, before the content. So
when they appear, they will reduce the amount of space usable for the control.
That is a little annoying, but preferable to the tabs totally not existing.

Relevant conversation notes from #10798:

> > If the info bar is not local to the tab, then its location between the tab
> > bar (when the title bar is hidden) and the terminal panes feels
> > misleading. Should it instead be above the tab bar or below the terminal
> > panes?
>
> You're... not wrong here. It's maybe not the best place for it, but _on top_
> of the tabs would look insane, and probably wouldn't even work easily, given
> the way we reparent the tab row into the titlebar.
>
> In the pane itself would make more sense, but that runs abreast of all sorts
> of things like #9024, #4998, which might make more sense.

I'm just gonna go with this now, because it's _better_ than before, while we
work out what's _best_.

![gh-11606-fix](https://user-images.githubusercontent.com/18356694/138729178-b96b7003-0dd2-4521-8fff-0fd2a5989f22.gif)
DHowett pushed a commit that referenced this issue Dec 13, 2021
…of (#11609)

Fixes #11606

This is weird, but the infobars would appear totally on top of the
TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar
obscuring the tabs.

Now, the infobars are strictly inserted after the tabs, before the content. So
when they appear, they will reduce the amount of space usable for the control.
That is a little annoying, but preferable to the tabs totally not existing.

Relevant conversation notes from #10798:

> > If the info bar is not local to the tab, then its location between the tab
> > bar (when the title bar is hidden) and the terminal panes feels
> > misleading. Should it instead be above the tab bar or below the terminal
> > panes?
>
> You're... not wrong here. It's maybe not the best place for it, but _on top_
> of the tabs would look insane, and probably wouldn't even work easily, given
> the way we reparent the tab row into the titlebar.
>
> In the pane itself would make more sense, but that runs abreast of all sorts
> of things like #9024, #4998, which might make more sense.

I'm just gonna go with this now, because it's _better_ than before, while we
work out what's _best_.

![gh-11606-fix](https://user-images.githubusercontent.com/18356694/138729178-b96b7003-0dd2-4521-8fff-0fd2a5989f22.gif)

(cherry picked from commit a916a5d)
DHowett pushed a commit that referenced this issue Dec 13, 2021
…of (#11609)

Fixes #11606

This is weird, but the infobars would appear totally on top of the
TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar
obscuring the tabs.

Now, the infobars are strictly inserted after the tabs, before the content. So
when they appear, they will reduce the amount of space usable for the control.
That is a little annoying, but preferable to the tabs totally not existing.

Relevant conversation notes from #10798:

> > If the info bar is not local to the tab, then its location between the tab
> > bar (when the title bar is hidden) and the terminal panes feels
> > misleading. Should it instead be above the tab bar or below the terminal
> > panes?
>
> You're... not wrong here. It's maybe not the best place for it, but _on top_
> of the tabs would look insane, and probably wouldn't even work easily, given
> the way we reparent the tab row into the titlebar.
>
> In the pane itself would make more sense, but that runs abreast of all sorts
> of things like #9024, #4998, which might make more sense.

I'm just gonna go with this now, because it's _better_ than before, while we
work out what's _best_.

![gh-11606-fix](https://user-images.githubusercontent.com/18356694/138729178-b96b7003-0dd2-4521-8fff-0fd2a5989f22.gif)

(cherry picked from commit a916a5d)
@ghost
Copy link

ghost commented Dec 14, 2021

🎉This issue was addressed in #11609, which has now been successfully released as Windows Terminal Preview v1.12.3472.0.:tada:

Handy links:

@ghost
Copy link

ghost commented Dec 14, 2021

🎉This issue was addressed in #11609, which has now been successfully released as Windows Terminal v1.11.3471.0.:tada:

Handy links:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants