The current traffic light controls are substantially broken, due to being custom buttons rather than the native controls.
This creates the following problems:
we don't see the correct icons when hovered
hover state isn't always picked up correctly, as they seem to fight with other toolbar buttons
hovering over the green button doesn't show the native macOS tiling options
when in full-screen mode, the traffic lights don't move to the title bar (invoked by hovering)
holding down option and clicking on green doesn't fill
All of those - apart from the fighting with other buttons for hover - would be solved by using the native controls.
However, the native buttons don't behave exactly like Arc, as they made the choice to grey out the native icons and only show the colours (and icons) when hovered. I wrote to them a couple of years ago pointing out that is explicitly against HIG, but didn't hear back. In every other macOS app, if the window is front-most/active, then the colours are shown to indicate to the user which app will receive input - for example, CMD+Q. I personally don't agree with Arc's breaking of this fundamental convention and would prefer to see the idiomatic use of window control buttons.
I understand that people may disagree with that view and prefer to emulate Arc, hence why I haven't put in a PR, but created an issue. I would also feel dirty implementing the "wrong" approach.
Luckily, there's another opensource project (Zen) that has a working example of Arc's implementation, without the broken functionality I listed out above. So the below should be helpful for anyone wanting to do it that way.
CSS: Grey dot visuals
Traffic light styling block (L200-236)
Reversed button margin adjustment (L238-243)
JS: Hover detection (ZenCompactMode)
hoverableElements getter registering actualWindowButtons (L587-604)
_setElementExpandAttribute toggling zen-has-hover (L632-665)
Hover listeners on hoverable elements (L681-764)
JS: Button element & positioning (ZenUIManager)
isWindowsStyledButtons lazy getter (L786-791)
actualWindowButtons getter (L962-971)
zen-window-buttons-reversed attribute set (L821-823)
Window button positioning logic (L1153-1281)
The current traffic light controls are substantially broken, due to being custom buttons rather than the native controls.
This creates the following problems:
we don't see the correct icons when hovered
hover state isn't always picked up correctly, as they seem to fight with other toolbar buttons
hovering over the green button doesn't show the native macOS tiling options
when in full-screen mode, the traffic lights don't move to the title bar (invoked by hovering)
holding down option and clicking on green doesn't fill
All of those - apart from the fighting with other buttons for hover - would be solved by using the native controls.
However, the native buttons don't behave exactly like Arc, as they made the choice to grey out the native icons and only show the colours (and icons) when hovered. I wrote to them a couple of years ago pointing out that is explicitly against HIG, but didn't hear back. In every other macOS app, if the window is front-most/active, then the colours are shown to indicate to the user which app will receive input - for example, CMD+Q. I personally don't agree with Arc's breaking of this fundamental convention and would prefer to see the idiomatic use of window control buttons.
I understand that people may disagree with that view and prefer to emulate Arc, hence why I haven't put in a PR, but created an issue. I would also feel dirty implementing the "wrong" approach.
Luckily, there's another opensource project (Zen) that has a working example of Arc's implementation, without the broken functionality I listed out above. So the below should be helpful for anyone wanting to do it that way.
CSS: Grey dot visuals
Traffic light styling block (L200-236)
Reversed button margin adjustment (L238-243)
JS: Hover detection (ZenCompactMode)
hoverableElements getter registering actualWindowButtons (L587-604)
_setElementExpandAttribute toggling zen-has-hover (L632-665)
Hover listeners on hoverable elements (L681-764)
JS: Button element & positioning (ZenUIManager)
isWindowsStyledButtons lazy getter (L786-791)
actualWindowButtons getter (L962-971)
zen-window-buttons-reversed attribute set (L821-823)
Window button positioning logic (L1153-1281)