Description of the issue: As soon as about week ago, there was an experimental flag for disabling the traffic light buttons on mac on top-left corner. The traffic light would only appear after hovering over the very top of the screen (by touching the top border of the screen). After updating to this new version, the flag stopped flagging, and I’m stuck with the ugly traffic light which only takes space
How can this issue be reproduced? Open Brave on MacOS
Expected result: No traffic light (3 mac buttons).
Brave Version: 1.89.132 Chromium: 147.0.7727.56 (Official Build) (arm64)
Additional information: I realized, that I also updated MacOS recently, it could be assiciated with that software update.
The Red, Yellow, and Green MacOS window control buttons - their location in the MacOS Finder window code / an application’s windows’ code … is occasionally changed - meaning, that the path to their button attributes, changes.
So, an experimental flag loses track.
What ChatGPT had to say:
What changed under the hood
There are two overlapping shifts:
1. Chromium UI refactor (recent)
- Brave 1.87–1.89 is based on new Chromium (145–147)
- There are active bugs around window controls + hover behavior (fullscreen overlay, tab merging, etc.)
- Chromium has been reworking:
- tab strip + title bar integration
- window controls overlay behavior
- Views framework event handling
This often breaks flags that relied on:
- specific view hierarchies (
BrowserFrameViewMac, etc.) - hardcoded offsets / hit-testing zones
- hover regions tied to old titlebar logic
2. MacOS changes (Sonoma → Sequoia era)
MacOS has also been evolving:
- More aggressive “toolbar-on-hover” / immersive fullscreen behavior
- Different layering of:
- titlebar
- toolbar
- traffic lights (NSWindow buttons)
Result:
Chromium apps that fake native titlebars (like Brave) now have to:
- either defer to MacOS APIs more
- or reimplement positioning differently
That breaks hacks like:
“only show buttons when cursor hits top edge”
“show buttons on hover region”
Why your specific flag died
That flag likely did something like:
- override visibility of
NSWindowstandard buttons - or intercept hover hit-testing at the top inset
Now:
- the buttons may be owned/positioned differently
- or composited in a different layer
- or controlled by macOS instead of Chromium
So the flag still exists (or did), but:
it no longer affects the actual rendered controls
Key insight (important)
This kind of flag is inherently fragile.
From a Chromium perspective, it’s:
- not a stable API
- not a supported customization path
- often tied to internal class names / layout assumptions
So when either:
- Chromium refactors UI
- OR MacOS changes NSWindow behavior
the flag silently stops working (exactly what you’re seeing)
Practical takeaway
You’re not missing anything — this is not user error.
Your options now are basically:
1. Wait for Brave to reintroduce it
If enough people complain, they might:
- re-hook into the new layout system
- or expose a new flag
2. Use MacOS-native behavior
Closest equivalent:
- fullscreen + top-edge hover (Apple-controlled)
- but less customizable
3. External hacks (less stable)
- SIMBL / injection tools
- window manager tweaks
…but these are even more brittle than flags.
Bottom line
Yes — your guess is correct:
The flag broke because the code path / UI hierarchy for MacOS window controls changed, likely due to a mix of Chromium refactoring + MacOS updates, so the flag no longer targets the right elements.
Related issues:
Good illustrations of the problem:
‘Fullscreen Mode Issues on MacOS’
‘macOS Titlebar on full screen mode must be fixed’
‘Mac fullscreen is nearly unusable since this change’
‘macOS Fullscreen: Top Title Bar Covers Tabs When Hovering Too Far Up’
‘macOS fullscreen: toolbar hover hides Brave tab bar’
Brave GitHub issues:
[macOS] In full screen, buttons bar covers the content when hovered #54180
‘https://github.com/brave/brave-browser/issues/54180’
trafficLightPosition not respected with titleBarStyle “customButtonsOnHover” #48463
‘https://github.com/electron/electron/issues/48463’
titleBarOverlay causes setWindowButtonPosition miscalculation in MacOS Tahoe #49183
‘https://github.com/electron/electron/issues/49183’
I’mean Chat only said what you did in more text. I’ve been trying to fix it using some “hacks” an AI, however, those tries haven’t gone exactly right.
Thanks for the help regardless, I’ll post here if I come up with something, so others can see a possible solution.
As soon as I installed the most recent brave version, I started having this issue too. Super annoying waste of space. If I want to press the traffic light buttons, I’ll just move my cursor up there anyway!
See:
‘https://github.com/brave/brave-browser/blob/master/CHANGELOG_DESKTOP.md’
and latest stable release version of Brave Browser: 1.89.141
Cool they fixed it, but I don’t think it is related or will fix our traffic-light problem