Open Bug 1899598 Opened 4 months ago Updated 5 hours ago

Hide the tabstrip toolbar and allow the nav bar to be a titlebar when using vertical tabs

Categories

(Firefox :: Sidebar, enhancement, P2)

enhancement
Points:
8

Tracking

()

People

(Reporter: sclements, Assigned: sfoster, NeedInfo)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fidefe-sidebar])

Attachments

(4 files)

The second part of bug 1899346 is to hide the tabs toolbar and move the red/yellow/green window controls into the nav toolbar per the spec. We'll need to make sure this looks okay across all platforms. I don't think this bug is dependent on bug 1899346 but its probably worth checking in with sfoster this.

Assignee: nobody → nsharpley
Assignee: nsharpley → sfoster

One fun thing here is that window activeness normally changes the background color (edit: was "background title", I typoed) of the titlebar (and thus tabstrip). And the address bar / navbar is... not prepared for this. I suspect this isn't fully specced - especially as on e.g. Linux the background colour is controlled by the OS theme so is not predictable.

Yeah I think it'd make sense to treat the toolbar like a titlebar in this case...

(In reply to :Gijs (he/him) from comment #1)

One fun thing here is that window activeness normally changes the background title of the titlebar (and thus tabstrip). And the address bar / navbar is... not prepared for this. I suspect this isn't fully specced - especially as on e.g. Linux the background colour is controlled by the OS theme so is not predictable.

When you say "changes the background title" can you clarify? I see that the inactive windows title/toolbar/tabstrip/buttons are lightly grayed out (on macOS system theme). Is there something else happening? A screenshot would be helpful.

Sure. Notice in this screenshot that the active (bottom) and inactive (top) window have different background and foreground colours in the titlebar. They are different shades of grey on Windows. We have a bug on file (bug 1704131) that the difference is too subtle; this is a bit of a usability issue because of course, if you're typing or otherwise interacting with stuff (and not the kind of person who maximizes all their windows on a single screen) then knowing which window has focus (is active) is kind of important.

The default state on Linux is that we use the OS-defined colours in this case, which are more significantly different.

On Windows, the same behaviour can be turned on behind an about:config pref. bug 1851155 is on file about potentially making that the default behaviour. I'll attach a screenshot of that next.

Edit: Oh, and notice that the navbar styling is currently identical between the active/inactive windows.

Because it's an about:config pref (which I think is not exposed anywhere in the UI?) we probably don't need to spend a lot of time on this configuration on Windows - but we'll need to support the equivalent on Linux, and even the different shades of grey on Windows are likely to require additional styling work.

I'm not familiar off-hand with how this is expressed in CSS; if we're lucky it's a bunch of variables that we can "just" update in the "right" circumstances; if we're less lucky it'll need more substantial changes.

:mconley, with your recently re-acquired CUI/tabbed-browser context, would you be able to provide some feedback on this WIP patch? ISTM we can either do this entirely with CSS, entirely with the existing CSS but moving elements around, or some combination of both. Also, :dao - at the risk of inviting too many cooks into the kitchen - do you have thoughts on how we want this to happen?

Flags: needinfo?(mconley)
Flags: needinfo?(dao+bmo)

(In reply to :Gijs (he/him) from comment #5)

Because it's an about:config pref (which I think is not exposed anywhere in the UI?) we probably don't need to spend a lot of time on this configuration on Windows - but we'll need to support the equivalent on Linux, and even the different shades of grey on Windows are likely to require additional styling work

High Contrast Mode also does this on Windows, and we do care about that, right?

I'm not familiar off-hand with how this is expressed in CSS; if we're lucky it's a bunch of variables that we can "just" update in the "right" circumstances; if we're less lucky it'll need more substantial changes.

Yes, these are the ActiveCaption / CaptionText / InactiveCaption / InactiveCaptionText system colors.

(I responded with some feedback in Phabricator, so clearing needinfo)

Flags: needinfo?(mconley)
  • Ensure we call TabBarVisibility.update when initializing with verticalTab=true
  • Adjust TabBarVisibility logic so we allow for the vertical tabs case
Attachment #9424544 - Attachment description: WIP: Bug 1899598 - Make nav-bar a child of #titlebar and hide the horizontal tab strip when vertical tabs are enabled. r?mconley! → Bug 1899598 - Hide the horizontal tab strip when vertical tabs are enabled. r?mconley!
Flags: needinfo?(dao+bmo)

Just adjusting the bug title as this turned out to involve tabs-in-titlebar logic changes as well as the important toolbar visibility change when going to/from vertical tabs.

Severity: -- → N/A
Type: task → enhancement
Points: --- → 8
Summary: Update nav bar styling for vertical tabs → Hide the tabstrip toolbar and allow the nav bar to be a titlebar when using vertical tabs
Pushed by sfoster@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0b970f2cd8fd Hide the horizontal tab strip when vertical tabs are enabled. r=mconley,desktop-theme-reviewers,tabbrowser-reviewers,sidebar-reviewers,emilio,willdurand,sclements

Backed out for causing devtools failures in browser_aboutdebugging_devtoolstoolbox_tooltip_markupview.js

  • Backout link
  • Push with failures
  • Failure Log
  • Failure line: TEST-UNEXPECTED-FAIL | devtools/client/aboutdebugging/test/browser/browser_aboutdebugging_devtoolstoolbox_tooltip_markupview.js | Uncaught exception in test bound - at chrome://mochitests/content/browser/devtools/client/aboutdebugging/test/browser/browser_aboutdebugging_devtoolstoolbox_tooltip_markupview.js:89 - TypeError: can't access property "ownerGlobal", elementForHiding is null
Flags: needinfo?(sfoster)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: