I’m using vertical tabs without title bar. It makes no sense to me that the currently opened tab shows an (x) instead of the favicon of the website! It should show the (x) on mouse hover ONLY (if that), not all the time. Tested both on windows and macOS.
Note the (x) above Gmail for the brave community website (instead of the brave favicon).
Extra: even better if there was a setting to completely hide the (x). I always close tabs using the middle button of the mouse, or ctrl+w/cmd+w if it’s the active tab; even on touchpad, three-finger click == middle button click, so no need for the (x). The setting could be: [show on active tab, show on active tab on mouseover, never show].
The current behavior is “show on active tab”, which is odd to me!
Not sure what you consider unreasonable. Do you consider it unreasonable to have the option to completely hide the (x)?
I strongly believe that’s the better experience for “advanced” users. Like I said, there are many ways to close a tab. I don’t really use the (x); ctrl+w/cmd+w if my hand is on the keyboard, middle button click if it’s on the mouse. I don’t need anything else. Do notice that I’m suggesting the OPTION of hiding the (x). I’m neither suggesting that the (x) should be removed for everyone without a way to enable it, nor suggesting it should be the default behaviour.
Why do I think that’s the better experience? See for yourself. Enable vertical tabs, then collapse the tab panel (so only the favicons show up).
Try to move the tab (drag&drop it somewhere else). It’s hard. You have to be very careful to not click the (x), and instead click on the few pixels around the (x). I usually use ctrl+shift+fn+up/down if I just want to move one tab; but when I want to reorganize many tabs, I prefer to use the mouse to move them around, since in that case that’s the faster approach.
Try to right click the tab to open the menu. Same problem, the (x) is in the way. I right click for things I don’t know the shortcut (e.g. mute/unmute tab/site, pin/unpin, or to add tab to a new tab group).
If the (x) shows up on mouse hover, then these issues aren’t solved, because to drag&drop or right click you need to mouse hover…
I said it’s unreasonable because the majority of vertical tab users are not using that feature collapsed and even the ones who are, the majority of that minority are not going to use the middle click to close a tab. You are in the fringe minority who would use it that way, so ask yourself if it’s reasonable for developers to create a new feature that so very few will ever use.
That’s all I meant by unreasonable.
I definitely agree on your first suggestion, though.
Ah, I get it now. I think if someone is already touching the part of the code that decides whether to render the close button on the tab or not, I doubt it would be any harder to implement that third option. Here’s some pseudocode:
Currently: showCloseButton = true
With first suggestion: showCloseButton = getConfig("displayCloseButton") == "always" || isHovered
With second suggestion: showCloseButton = getConfig("displayCloseButton") == "always" || (getConfig("displayCloseButton") == "onMouseHover" && isHovered)
The harder part is all the work around this line: setting up the environment to work on brave (clone repo, install deps, etc), adding a new config, finding where in the code the button is rendered, adding this one-line logic to decide whether to render, writing and running unittests, compiling the browser and testing the feature, then opening a PR.
