Traffic light flag

Brave Browser Desktop Support
,
4

@Lidr

What ChatGPT had to say:

:gear: 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

:backhand_index_pointing_right: 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)

:backhand_index_pointing_right: 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”

:collision: Why your specific flag died

That flag likely did something like:

  • override visibility of NSWindow standard 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

:backhand_index_pointing_right: So the flag still exists (or did), but:
it no longer affects the actual rendered controls

:test_tube: 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

:backhand_index_pointing_right: the flag silently stops working (exactly what you’re seeing)

:compass: 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.

:brain: 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’