Gerd Möllmann writes: > Jones Stephen writes: > >> Dear Emacs Developers, >> >> I am encountering an issue with window-absolute-pixel-position on macOS that leads to incorrect Y-coordinate values under specific conditions. This >> bug appears to manifest in two scenarios: after the system resumes from sleep, and when Emacs is in fullscreen mode. >> >> Environment: >> >> Emacs Version: (30.0.50) >> Operating System: macOS (After 14.00) >> Issue Description: >> >> After Sleep: When macOS resumes from sleep, the Y-coordinate value returned by window-absolute-pixel-position is off by approximately one-fourth >> of the screen height. >> During Fullscreen Mode: In fullscreen mode, the Y-coordinate is incorrectly offset by the height of the navbar. >> Steps to Reproduce: >> >> Open Emacs and position a window at a known pixel position. >> Either put the system to sleep and wake it, or switch Emacs to fullscreen mode. >> Evaluate (window-absolute-pixel-position) and note the Y-coordinate. >> Expected Behavior: >> The function should return accurate window positions regardless of sleep mode or fullscreen state, without any unexpected offsets. >> >> Actual Behavior: >> The Y-coordinate is inaccurately calculated, showing a significant offset that seems to be influenced by system sleep and fullscreen transitions. >> >> This issue can be particularly disruptive in workflows that rely on precise window positioning, such as automated GUI testing or window management >> scripts. Any insights or fixes would be greatly appreciated! >> >> Thank you for your attention to this matter. >> >> Best regards, >> happyo > > I can reproduce this (only tried the fullscreen case), but I don't know > how to fix it. In a fullscreen frame, eval > > (ns-frame-edges (selected-frame) 'native-edges) > -> (566 39 2290 1107) > > That is, both left and top are bogus values. Also, > > (frame-parameter (selected-frame) 'fullscreen) > -> fullboth > (frame-parameter (selected-frame) 'top) > -> 39 > (frame-parameter (selected-frame) 'left) > -> 566 > > which is why ns-frame-edges in its current implementation returns these > values for left and top. Don't know what is expected here. Should top > and left frame parameters have been set to 0 somewhere? Or is the > implementation of ns-frame-edges wrong in using top_pos and left_pos of > the frame? The following patch for master addresses this at least partially. Part of the problem is, it appears to me, is that windowDidMove is not called when entering/exiting fullscreen mode, so that a frame's left_pos and top_pos are not adjusted. The patch tries to fix that. I haven't found out what to do with the frame parameters top and left. (Alan Third CC'd)