I can't move mac window buttons

Pathduck

@osbulbul Hello and Welcome to the Vivaldi Community

I'm not on MackyOZ so I can't check, but if it's the same selectors as on Windows (just guessing), this might work:

.window-buttongroup button {
	height: 30px !important;
}

Change the 30 to whatever works best, I believe 30px is about the smallest you can get the address bar without it looking wonky.

Possibly, try removing the "button" part, again no idea how the code looks on Mack.

If this isn't working you'll have to wait for someone who uses Macks. Or learn to inspect the UI yourself, it's not difficult.
https://forum.vivaldi.net/topic/16684/inspecting-the-vivaldi-ui-with-devtools

AltCode

@Pathduck @osbulbul I'm afraid that won't work. The window buttons in macOS (commonly referred as the "traffic lights" buttons) can no longer be modified via CSS mods. See the following posts by @qjava as to why:

Vivaldi was using CSS to mimic native macOS window buttons before (and hence why custom CSS mods could modify them), but as of version 6.7, they are truly native.

This was done so that Vivaldi could support the Split View feature, as well as numerous third-party window managers/accesibility apps (e.g. Moom), and macOS 15's upcoming tiling and window manipulation options.

osbulbul

@AltCode ah i see. its sad to we can't even move it but thanks for clarifying

Do you know at least any settings to make address bar smaller/more compact? I think its just invades more than enough vertical space.

And @Pathduck thanks for welcome

Pathduck

@AltCode Thanks for the clarification.

Is there really no container element at all for the buttons?

From the image it looks like the container height is too large and causes the buttons to be misaligned.

But if there's no container to style, no CSS can change it - too bad...

AltCode

@osbulbul Sorry, there's not really any options for making it more compact.

Though if you're will to experiment, I guess you could hide the address bar entirely; that would certainly make things more compact.

In such a case, you can access the address bar with the "Focus Address Field" command (assigned to cmd-L by default). That would look like this:

AltCode

@Pathduck The container is still technically on macOS, but the buttons are not actually in it, and is instead completely empty (as seen from the DOM):

Pathduck

@AltCode OK that's what I suspected, at least there's a container. So the following should (in theory) change the height of the container and fix the position of the buttons.

.window-buttongroup {
	height: 30px !important;
}

Then again, it does say 0 height which might indicate it's already set as small "as possible" so not sure what they're doing here.

AltCode

@Pathduck Sorry, but that CSS also doesn't do anything.

As I mentioned, the buttons are not actually in the container, therefore they are not in the DOM.

EDIT: In fact, if I force the container to be at its absolutely smallest size possible (0x0), this happens:

Pathduck

@AltCode said in I can't move mac window buttons:

As I mentioned, the buttons are not actually in the container, therefore they are not in the DOM.

Yes, but here's code from common.css:

.mac#browser .window-buttongroup,
.linux.alt#browser .window-buttongroup {
  transform-origin: top left;
}

So that's the code that moves the buttons to the top left. And if you can move an element, it should be possible to do other things like hiding it (display: none; and possibly changing its position to absolute (position: absolute) and the setting the top offset like top: 5px or something to fix the misalignment.

EDIT: In fact, if I force the container to be at its absolutely smallest size possible (0x0), this happens:

Yes, looks like the buttons are just rendered on top of the element, natively.

This is the code for the width and margins:

:not(.fullscreen)#browser.mac .window-buttongroup {
  position: relative;
  display: inline-flex;
  min-width: calc(54px / var(--uiZoomLevel));
  margin-top: calc(13px / var(--uiZoomLevel));
  margin-left: calc(8px / var(--uiZoomLevel));
}
:not(.fullscreen)#browser.mac .window-buttongroup.on-mainbar {
  margin-top: 0;
  margin-right: 18px;
}
.tabs-top:not(.fullscreen)#browser.mac .window-buttongroup {
  margin-left: calc(13px / var(--uiZoomLevel));
}

Playing with the margin values would likely get the element to move so it can be placed correctly on top of the address bar when it's made lower.

I notice the element has a class of .window-buttongroup.on-mainbar - this has a margin-top of 0 so that would override the 13px from the other selector. Possibly one would need to use negative margins here - ugly but might work.

osbulbul

@Pathduck unfortunately nothing works. .window-buttongroup.on-mainbar is just there for creating empty space. I can move that div with negative (or positive) margins but buttons not moving with it.

So that buttons have no connection with window.html. They are not even following .window-buttongroup divs location. I think Vivaldi just putting buttons there from native with static x,y position.

AltCode

@Pathduck said in I can't move mac window buttons:

Yes, but here's code from common.css:

I think all of that is just legacy code from pre-6.7 versions though. In fact, in my attempts to override all of that, it doesn't seem to do anything (the container really only seems to be there to add empty space for other addressbar buttons), but perhaps it would be better if a dev like @qjava chimed in, because at this point if mostly feels like we are speculating the function of that CSS code.

What I can tell you though, is that if I remove the .window-buttongroup container from the DOM... nothing happens to the buttons either!

AltCode

@osbulbul Actually, if completely hiding the address bar is not to your liking, I just remembered that there is one other setting that does change the position of the window buttons: "Show Title Bar", found in vivaldi://settings/appearance/. If you enable that and combine it with the following CSS:

#browser:not(.fullscreen):not(.address-top-off, .address-bottom-off, .address-bottom) #header {
    display: none;
}

#browser:not(.address-top-off, .address-bottom-off, .address-bottom) .mainbar:not(:has(.window-buttongroup.on-mainbar)) {
    min-height: calc(35px / var(--uiZoomLevel));
}

#browser:not(.fullscreen):not(.address-top-off, .address-bottom-off, .address-bottom) .mainbar:not(:has(.window-buttongroup.on-mainbar)) {
    padding-left: calc(68px / var(--uiZoomLevel));
}

#browser:not(.address-top-off, .address-bottom-off, .address-bottom) .mainbar > .toolbar-mainbar {
    min-height: calc(34px / var(--uiZoomLevel));
}

You should get something closer to what you showed in your original screenshot:

Of course, you still can't do anything else about the exact position of the window buttons, but imo it is the best you can get with their current limitations.

osbulbul

@AltCode wow it helps

thank you so much for your time and effort, I am happy with this result.

qjava

@AltCode said in I can't move mac window buttons:

it doesn't seem to do anything (the container really only seems to be there to add empty space for other addressbar buttons)

This is exactly what it does and why it exists, the reason for this is to add spacing for native buttons that the UI layer has no idea about