GNU bug report logs - #71912
30.0.50; Inaccurate window-absolute-pixel-position Values on macOS After Sleep and During Fullscreen Mode

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Jones Stephen <happyojones <at> gmail.com>
Cc: Alan Third <alan <at> idiocy.org>, 71912 <at> debbugs.gnu.org
Subject: bug#71912: 30.0.50; Inaccurate window-absolute-pixel-position Values on macOS After Sleep and During Fullscreen Mode
Date: Thu, 25 Jul 2024 09:39:16 +0200

[Message part 1 (text/plain, inline)]

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Jones Stephen <happyojones <at> gmail.com> 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)

[0001-macOS-adjust-frame-position-when-entering-exiting-fu.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.