Feature: remove tab bar margin. Extend tabs to the top of the titlebar.

[Erquint]

What feature or improvement do you think would benefit Files?

I need the waste of space above the tab bar gone.

It makes me miss the tabs with my mouse pointer by going too high.

It's not even like it can be used for dragging the window. 🤷‍♂️

The actual drag handle

I'm using Files fullscreen anyway.
The only purpose I'm noticing so far of that margin is to make my life harder.
Either make it an option, make it adapt or get rid of it completely.

There's a reason web browsers extend tabs all the way to the top of the titlebar when fullscreen.

Windowed

Fullscreen

They also leave additional space between the tab controls and the window controls as a fallback at all times, which is fine, I guess.

Think I cropped the screenshots short..? Try with your own browser of choice and see for yourself.

Please use their insight.

Requirements

In fullscreen mode, the very top pixel row of the screen must accept tab clicks from the mouse pointer.

Files Version

3.7.11.0

Windows Version

10.0.19045.4412

Comments

No response

[Lamparter]

This is an interesting proposal. The TabView control is designed to have this margin to be in alignment with the WinUI design language, don't you think that removing the margin would betray that?

[Josh65-2201]

Thanks for the feedback, the drag area between window controls and tabs are suppose to be like browsers but doesn't always so. We're tracking this in #14958. You can check there or click subscribe in the right sidebar for updates.

[yaira2]

Please refer to #16427. I agree in principle about removing the gap in full screen mode. In fact, earlier versions did not have this gap, but the overwhelming feedback indicated that it's natural for users to move the cursor to the top of the screen to grab the window.

[Erquint]

Those issues are distinct.

Requirements
In fullscreen mode, the very top pixel row of the screen must accept tab clicks from the mouse pointer.

vs

Requirements
Make sure a drag gap is always present between the tabs and window controls

vs

Requirements

• move the location of open tabs (if the user wants this option active).
• change in the location of some buttons.

As for:

overwhelming feedback indicated that it's natural for users to move the cursor to the top of the screen to grab the window

That really sounds like one of those collective misunderstandings of own needs and misrecollection of own experiences.
If they had such a habit from other tabbed programs — it would most likely be from browsers.
But browsers don't in fact leave a gap on top as I pointed out.
My reasoning is based on a commonly accepted design principle all users are well-accustomed to in actual practice.

I showed what Edge does.

Firefox

Windowed

Fullscreen

Yes, no difference.

Chrome

Windowed

Fullscreen

Yes, no difference either.

Edge adapts unlike other ones.
But all browsers have the top row of pixels pick tabs.
Not one leaves a gap there: neither dead nor draggy.

So as much as I despise saying it: users don't know what they want.
Again, I'm asking for a conventional commonality.

P. S.

Looking back at the screenshot I realize now that Chrome's can make it seem like there's a gap, but be assured there isn't one — test yourself, you have a Chrome… Top row of pixels picks tabs.

[Erquint]

Windows 11 Explorer.

Windowed

Fullscreen

It adapts like Edge.
M$ seems to like adapting.

Asked a friend on Windows 11 to help with screenshots.
He reports also being able to select tabs by clicking on the top pixel row.

[yaira2]

Personally, I favor matching the behavior of web browsers. However, this approach was previously tried in Files (we had a neat helper class to detect the window state), but users requested to revert the behavior in favor of having a drag region (which, unfortunately, is currently non-functional due to a bug in WinUI).

That was a couple of years ago, so things might be different now. I'll keep an eye out for similar feedback and will remain open to reconsidering this if there's more interest in heading in that direction.

[Josh65-2201]

I would also prefer it act like a browser but #14958 might need to be fixed first

[yaira2]

I haven't been able to repro that but hopefully both issues will be solvable when the WinUI TitleBar control is released.