Repository navigation
Fix: the end control never receives clicks on macOS 27 (click lands at the item's centre) - #134
Pongchayanneung wants to merge 2 commits into
Conversation
On macOS 27 a click on a status item reports its location at the centre of the item's window, so SwiftUI saw every click land on the countdown and the end control at the right edge was never reached. A local mouse monitor now reads the pointer position on screen and ends the session when the click falls in the right-hand 30pt while a session runs. The control also ends on release instead of requiring a completed hold. README and spec updated. Co-Authored-By: Claude Sonnet 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_0186aQ2a3QihzStd6T8WrfZv
Co-Authored-By: Claude Sonnet 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_0186aQ2a3QihzStd6T8WrfZv
Real-Mac report for 8e76572Build. Clean checkout of the head commit, installed with Mac. Built-in display with a notch. On battery, Low Power Mode was already on before the run ( Checks. Only one item in "Real-Mac checks before a release" is affected by this change: "Normal end ... restore live power state", here ended by the user with the end control. Steps: 10:05:33 launch the app (no session to restore). 10:05:46 start a 1 hour session. 10:05:59 one real left click (CGEvent mouse down/up) on the end control at the right edge of the status item. Result: pass, the session ended on that single click and sleep was restored.
(Times in the log are UTC, the samples below are +07. The notification authorization lines are left out; notifications are not allowed for the app on this Mac.) pmset samples, started before the check and left running (time,
The recovery agent after the run: Before this change, on the same Mac, the same click on the end control opened the Days / Hours / Minutes pills and the session kept running (the cause is in the PR description). Not run. The rest of "Real-Mac checks before a release" does not touch the status item's click handling, so I did not run it: force-quit and deadline recovery, reboot and login, lid close and the lid simulation build, Low Power Mode on macOS 27, thermal, hotspot, freezing and audio checks, and the release channel checks. I also did not click the countdown to check that it still opens the extend pills (it sits about 36 pt from the right edge, outside the 30 pt zone). I did not test an Intel Mac or macOS 26 by hand. |
What changes
On a MacBook Pro with a notch running macOS 27, the end control (the circled x next to the countdown) never ends a session, however it is pressed. A click on a status item reports its location at the centre of the item's window, whatever was clicked. SwiftUI therefore sees every click land on the countdown, which opens the Days / Hours / Minutes pills to extend, and the end control at the right edge is never hit. The same flaw sends a click on a pill to the middle pill.
Evidence from a debug build (button 118 pt wide, real click at the end control, pointer 18 pt from the right edge):
With the session idle the same click on the 32 pt item gave 16.0, the centre again.
The fix reads the pointer from
NSEvent.mouseLocationin a localleftMouseDownmonitor. While a session runs, a click in the right 30 pt of the item ends it and the click is taken.HoldToEndButtonalso ends on release, so on a machine where the location is right a plain click works too.Scope note: this changes the end control from press-and-hold to click. If you want to keep the hold, the zone handler could start the ring instead. I did not do that.
Not fixed here: clicks on the pills still land on the middle pill on this Mac.
How it was tested
testEndZoneIsTheRightEdgeOfTheIteminUIStatusTests. I could not run it: this Mac has Command Line Tools only, soswift testfails withno such module 'XCTest'.swift buildpasses.pmset -gthen showsSleepDisabled 0and there is nosession.json.Real-Mac evidence
Draft. MacBook Pro (Apple Silicon, built-in Liquid Retina XDR display), macOS 27 (26A428). Only the check above was run. The other items in
docs/releasing.mdwere not run and I will not claim them. I have not opened an issue first, which CONTRIBUTING.md asks for before changing a default.🤖 Generated with Claude Code
https://claude.ai/code/session_0186aQ2a3QihzStd6T8WrfZv