Hide the tabstrip toolbar and allow the nav bar to be a titlebar when using vertical tabs
Categories
(Firefox :: Sidebar, enhancement, P2)
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.
Updated•4 months ago
|
Updated•3 months ago
|
Updated•2 months ago
|
Comment 1•2 months ago
•
|
||
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.
Comment 2•2 months ago
|
||
Yeah I think it'd make sense to treat the toolbar like a titlebar in this case...
Reporter | ||
Comment 3•1 month ago
|
||
(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.
Comment 4•1 month ago
•
|
||
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.
Comment 5•1 month ago
|
||
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.
Assignee | ||
Comment 6•1 month ago
|
||
Depends on D217161
Assignee | ||
Comment 7•1 month ago
•
|
||
: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?
Comment 8•21 days ago
|
||
(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.
Comment 9•21 days ago
|
||
(I responded with some feedback in Phabricator, so clearing needinfo)
Assignee | ||
Comment 10•18 days ago
|
||
- Ensure we call TabBarVisibility.update when initializing with verticalTab=true
- Adjust TabBarVisibility logic so we allow for the vertical tabs case
Updated•12 days ago
|
Updated•11 days ago
|
Assignee | ||
Comment 11•5 days ago
|
||
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.
Comment 12•9 hours ago
|
||
Comment 13•5 hours ago
|
||
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
Description
•