GNU bug report logs -
#71912
30.0.50; Inaccurate window-absolute-pixel-position Values on macOS After Sleep and During Fullscreen Mode
Previous Next
To reply to this bug, email your comments to 71912 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71912
; Package
emacs
.
(Wed, 03 Jul 2024 07:37:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jones Stephen <happyojones <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 03 Jul 2024 07:37:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
In GNU Emacs 30.0.50 (build 2, aarch64-apple-darwin23.3.0, NS
appkit-2487.40 Version 14.3 (Build 23D56)) of 2024-05-14 built on
happyo.local
Windowing system distributor 'Apple', version 10.3.2554
System Description: macOS 15.0
Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=/opt/homebrew/share/emacs/site-lisp
--infodir=/opt/homebrew/Cellar/emacs-plus <at> 30/30.0.50/share/info/emacs
--prefix=/opt/homebrew/Cellar/emacs-plus <at> 30/30.0.50 --with-xml2
--with-gnutls --without-compress-install --without-dbus
--without-imagemagick --with-modules --with-rsvg --with-webp --with-ns
--disable-ns-self-contained 'CFLAGS=-Os -w -pipe
-mmacosx-version-min=14
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk
-DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT'
'CPPFLAGS=-I/opt/homebrew/opt/icu4c/include
-I/opt/homebrew/opt/sqlite/include -I/opt/homebrew/opt/readline/include
-isystem/opt/homebrew/include -F/opt/homebrew/Frameworks
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk'
'LDFLAGS=-L/opt/homebrew/opt/icu4c/lib -L/opt/homebrew/opt/sqlite/lib
-L/opt/homebrew/opt/readline/lib -L/opt/homebrew/lib
-F/opt/homebrew/Frameworks -Wl,-headerpad_max_install_names
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk''
Configured features:
ACL GIF GLIB GMP GNUTLS JPEG LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS
PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER
WEBP XIM ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: ELisp/l
Minor modes in effect:
rainbow-delimiters-mode: t
smartparens-mode: t
olivetti-mode: t
electric-pair-mode: t
projectile-mode: t
hexl-follow-ascii: t
copilot-mode: t
lsp-bridge-mode: t
auto-insert-mode: t
yas-global-mode: t
yas-minor-mode: t
recentf-mode: t
savehist-mode: t
consult-notes-denote-mode: t
denote-menu-bar-mode: t
ns-auto-titlebar-mode: t
treemacs-filewatch-mode: t
treemacs-follow-mode: t
treemacs-git-mode: t
treemacs-fringe-indicator-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
server-mode: t
my-custom-minor-mode: t
windmove-mode: t
global-auto-revert-mode: t
vertico-posframe-mode: t
vertico-mode: t
meow-global-mode: t
meow-mode: t
meow-normal-mode: t
delete-selection-mode: t
meow-esc-mode: t
cnfonts-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
visual-line-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
~/.emacs.d/site-lisp/ob-swift-enhanced/spinner hides
/Users/belyenochi/.emacs.d/elpa/spinner-1.7.4/spinner
~/.emacs.d/site-lisp/vertico/vertico hides
/Users/belyenochi/.emacs.d/elpa/vertico-20240511.2047/vertico
/Users/belyenochi/.emacs.d/elpa/transient-20240609.2020/transient hides
/opt/homebrew/Cellar/emacs-plus <at> 30
/30.0.50/share/emacs/30.0.50/lisp/transient
Features:
(shadow sort mail-extr emacsbug goto-addr etags fileloop generator
tramp-cmds treemacs-mouse-interface display-line-numbers
treemacs-file-management hydra lv vc-hg vc-bzr vc-src vc-sccs vc-svn
vc-cvs vc-rcs log-view vc bug-reference magit-extras vc-git
vc-dispatcher rainbow-mode network-stream nsm rainbow-delimiters
smartparens loadhist olivetti elec-pair time init-macos mac-plugin
init-pomodoro init-swift ob-swift-enhanced xcode-build swift-refactor
swift-additions xcode-additions xcodebuildserver projectile ibuf-ext
ibuffer ibuffer-loaddefs ios-simulator ios-device periphery
periphery-helper mode-line-hud spinner ob-swift ob ob-tangle ol org-src
ob-ref ob-lob ob-table ob-exp ob-comint ob-core org-cycle org-fold
org-fold-core ob-eval org-keys oc org-compat org-macs async init-debug
dape eglot external-completion flymake ert ewoc hexl gdb-mi bindat gud
repeat swift-mode init-treesit swift-ts-mode c-ts-common treesit
init-copilot copilot copilot-balancer editorconfig editorconfig-core
editorconfig-core-handle editorconfig-fnmatch f jsonrpc init-lsp
apheleia apheleia-rcs apheleia-dp apheleia-formatters apheleia-utils
apheleia-log apheleia-formatter-context lsp-bridge
lsp-bridge-semantic-tokens lsp-bridge-dart lsp-bridge-inlay-hint
lsp-bridge-org-babel lsp-bridge-lsp-installer lsp-bridge-diagnostic
lsp-bridge-code-action acm acm-quick-access acm-backend-jupyter
acm-backend-org-roam acm-backend-copilot acm-backend-codeium
acm-backend-ctags acm-backend-citre acm-backend-tabnine
acm-backend-telega acm-backend-tempel acm-backend-search-sdcv-words
acm-backend-search-file-words acm-backend-path acm-backend-lsp
acm-backend-elisp acm-backend-yas acm-icon svg xml
lsp-bridge-call-hierarchy lsp-bridge-peek lsp-bridge-jdtls
lsp-bridge-ref grep lsp-bridge-epc acm-frame markdown-mode noutline
outline init-exec-path exec-path-from-shell init-yasnippet autoinsert
yasnippet lisp-mnt init-sessions dashboard dashboard-widgets recentf
tree-widget ffap thingatpt savehist init-denote consult-notes-denote
consult-notes denote-silo-extras denote init-org init-translate
go-translate go-translate-v2 gts-engine-youdao gts-engine-stardict
gts-engine-deepl gts-engine-google-rpc gts-engine-google gts-engine-bing
gts-implements gts-faces gts-core gt-text-utility gt-engine-echo
gt-engine-chatgpt gt-engine-youdao gt-engine-stardict gt-engine-deepl
gt-engine-google-rpc gt-engine-google gt-engine-bing gt-extension plz
warnings gt-faces gt-core let-alist dom init-mode-line init-gui-frames
ns-auto-titlebar init-themes cus-edit cus-load wid-edit
treemacs-nerd-icons treemacs treemacs-header-line treemacs-compatibility
treemacs-mode treemacs-bookmarks treemacs-tags xref project
treemacs-interface treemacs-persistence treemacs-filewatch-mode
treemacs-follow-mode treemacs-rendering treemacs-annotations
treemacs-async treemacs-workspaces treemacs-dom treemacs-visuals
treemacs-fringe-indicator pulse treemacs-faces treemacs-icons
treemacs-scope treemacs-themes treemacs-core-utils pfuture inline
hl-line ht treemacs-logging treemacs-customization treemacs-macros s
nerd-icons nerd-icons-faces nerd-icons-data nerd-icons-data-mdicon
nerd-icons-data-flicon nerd-icons-data-codicon nerd-icons-data-devicon
nerd-icons-data-sucicon nerd-icons-data-wicon nerd-icons-data-faicon
nerd-icons-data-powerline nerd-icons-data-octicon
nerd-icons-data-pomicon nerd-icons-data-ipsicon ef-summer-theme
chinese-color ef-themes init-magit magit-bookmark magit-submodule
magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull
magit-fetch magit-clone magit-remote magit-commit magit-sequence
magit-notes magit-worktree magit-tag magit-merge magit-branch
magit-reset magit-files magit-refs magit-status magit magit-repos
magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode
diff diff-mode track-changes git-commit log-edit message sendmail
yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg
rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev
mail-utils gmm-utils mailheader pcvs-util add-log magit-core
magit-autorevert magit-margin magit-transient magit-process with-editor
server magit-mode transient magit-git magit-base magit-section
cursor-sensor crm dash init-keybinding init-lisp init-treemacs
init-windows windmove init-editing-utils autorevert filenotify
init-search consult vertico-posframe vertico-multiform posframe vertico
compat fussy flx init-xterm vterm bookmark face-remap compile
text-property-search term disp-table ehelp vterm-module term/xterm xterm
vterm-toggle tramp-sh tramp trampver tramp-integration files-x
tramp-message tramp-compat xdg shell pcomplete comint ansi-osc ring
parse-time iso8601 time-date format-spec ansi-color tramp-loaddefs
init-projectile init-meow cl-extra meow meow-tutor meow-cheatsheet
meow-cheatsheet-layout meow-core meow-shims delsel meow-esc meow-command
array meow-beacon meow-thing meow-visual meow-keypad meow-helpers
meow-util color meow-keymap meow-face meow-var init-proxy init-osx-keys
edmacro kmacro init-chinese cnfonts touch-screen init-func init-elpa
use-package use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key use-package-core finder-inf
apheleia-autoloads easy-mmode async-autoloads
auto-package-update-autoloads cnfonts-autoloads dashboard-autoloads
default-text-scale-autoloads disable-mouse-autoloads
editorconfig-autoloads exec-path-from-shell-autoloads f-autoloads
format-all-autoloads fussy-autoloads flx-autoloads
ibuffer-projectile-autoloads imenu-list-autoloads indent-guide-autoloads
inheritenv-autoloads language-id-autoloads markdown-mode-autoloads
move-dup-autoloads ns-auto-titlebar-autoloads objc-font-lock-autoloads
olivetti-autoloads orderless-autoloads paradox-autoloads plz-autoloads
prettier-js-autoloads rainbow-delimiters-autoloads
rainbow-mode-autoloads slime-autoloads macrostep-autoloads
smartparens-autoloads smooth-scrolling-autoloads speed-type-autoloads
spinner-autoloads transwin-autoloads treemacs-icons-dired-autoloads
treemacs-magit-autoloads magit-autoloads pcase magit-section-autoloads
git-commit-autoloads transient-autoloads treemacs-nerd-icons-autoloads
nerd-icons-autoloads treemacs-projectile-autoloads projectile-autoloads
treemacs-tab-bar-autoloads treemacs-autoloads cfrs-autoloads
ht-autoloads hydra-autoloads lv-autoloads pfuture-autoloads
ace-window-autoloads avy-autoloads s-autoloads unicode-escape-autoloads
pp rx names edebug debug backtrace help-mode find-func dash-autoloads
names-autoloads advice vertico-posframe-autoloads vertico-autoloads
posframe-autoloads vterm-toggle-autoloads vterm-autoloads
vundo-autoloads wgrep-autoloads info with-editor-autoloads package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs icons
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)
Memory information:
((conses 16 1184799 9644722) (symbols 48 64280 2983)
(strings 32 386699 132024) (string-bytes 1 17501886)
(vectors 16 97354) (vector-slots 8 1735672 1510714)
(floats 8 1268 28445) (intervals 56 51964 36252) (buffers 992 85))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71912
; Package
emacs
.
(Tue, 23 Jul 2024 11:08:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 71912 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71912
; Package
emacs
.
(Thu, 25 Jul 2024 07:41:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 71912 <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71912
; Package
emacs
.
(Fri, 26 Jul 2024 19:26:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 71912 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 25, 2024 at 09:39:16AM +0200, Gerd Möllmann wrote:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> 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.
If you look at toggleFullScreen it creates a new NSWindow for
switching to fullscreen, or re-uses the old non-fullscreen NSWindow
when switching out of fullscreen, so the windows don't move.
You can actually just call windowDidMove directly. I'd suggest doing
it at the end of toggleFullScreen.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71912
; Package
emacs
.
(Fri, 26 Jul 2024 19:29:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 71912 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> On Thu, Jul 25, 2024 at 09:39:16AM +0200, Gerd Möllmann wrote:
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>> 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.
>
> If you look at toggleFullScreen it creates a new NSWindow for
> switching to fullscreen, or re-uses the old non-fullscreen NSWindow
> when switching out of fullscreen, so the windows don't move.
>
> You can actually just call windowDidMove directly. I'd suggest doing
> it at the end of toggleFullScreen.
Thanks, I'll give that a try tomorrow.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71912
; Package
emacs
.
(Fri, 26 Jul 2024 20:34:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 71912 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Alan Third <alan <at> idiocy.org> writes:
>
>> On Thu, Jul 25, 2024 at 09:39:16AM +0200, Gerd Möllmann wrote:
>>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>>
>>> 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.
>>
>> If you look at toggleFullScreen it creates a new NSWindow for
>> switching to fullscreen, or re-uses the old non-fullscreen NSWindow
>> when switching out of fullscreen, so the windows don't move.
>>
>> You can actually just call windowDidMove directly. I'd suggest doing
>> it at the end of toggleFullScreen.
>
> Thanks, I'll give that a try tomorrow.
Tried it today :-).
And it looks like toggleFullScreen is somehow not being used. When I
press the green button to go into fullscreen, I land in
windowDidEnterFullscreen, but it's called directly from AppKit. Similar
for exiting fullscreen.
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 8.1
frame #0: 0x0000000100365e54 emacs`-[EmacsView windowDidEnterFullScreen](self=0x000000014860f930, _cmd="windowDidEnterFullScreen") at nsterm.m:8350:4
frame #1: 0x0000000100365e30 emacs`-[EmacsView windowDidEnterFullScreen:](self=0x000000014860f930, _cmd="windowDidEnterFullScreen:", notification=@"NSWindowDidEnterFullScreenNotification") at nsterm.m:8344:3
frame #2: 0x0000000191b4f144 CoreFoundation`__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148
frame #3: 0x0000000191be33d8 CoreFoundation`___CFXRegistrationPost_block_invoke + 88
frame #4: 0x0000000191be3320 CoreFoundation`_CFXRegistrationPost + 440
frame #5: 0x0000000191b1d678 CoreFoundation`_CFXNotificationPost + 768
frame #6: 0x0000000192c3a4e4 Foundation`-[NSNotificationCenter postNotificationName:object:userInfo:] + 88
frame #7: 0x00000001961742b8 AppKit`-[NSWindow(NSFullScreen) _didEnterFullScreen] + 92
frame #8: 0x0000000195f568d8 AppKit`-[_NSEnterFullScreenTransitionController doAfterEnterFullScreen] + 208
frame #9: 0x0000000195f57710 AppKit`-[_NSEnterFullScreenTransitionController _performFinalTransitionCleanup] + 56
frame #10: 0x0000000195f5767c AppKit`__68-[_NSEnterFullScreenTransitionController _startFullScreenTransition]_block_invoke + 236
frame #11: 0x00000001918c8750 libdispatch.dylib`_dispatch_call_block_and_release + 32
frame #12: 0x00000001918ca3e8 libdispatch.dylib`_dispatch_client_callout + 20
frame #13: 0x00000001918d8bb8 libdispatch.dylib`_dispatch_main_queue_drain + 988
frame #14: 0x00000001918d87cc libdispatch.dylib`_dispatch_main_queue_callback_4CF + 44
frame #15: 0x0000000191b9bad4 CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
frame #16: 0x0000000191b59258 CoreFoundation`__CFRunLoopRun + 1996
frame #17: 0x0000000191b58434 CoreFoundation`CFRunLoopRunSpecific + 608
frame #18: 0x000000019c2fc19c HIToolbox`RunCurrentEventLoopInMode + 292
frame #19: 0x000000019c2fbfd8 HIToolbox`ReceiveNextEventCommon + 648
frame #20: 0x000000019c2fbd30 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76
frame #21: 0x00000001953b7d68 AppKit`_DPSNextEvent + 660
frame #22: 0x0000000195bad808 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700
frame #23: 0x00000001953ab09c AppKit`-[NSApplication run] + 476
frame #24: 0x000000010035b4bc emacs`-[EmacsApp run](self=0x0000000149005bf0, _cmd="run") at nsterm.m:5952:7
frame #25: 0x0000000100359b38 emacs`ns_select_1(nfds=0, readfds=0x000000016fdfd24c, writefds=0x000000016fdfd1cc, exceptfds=0x0000000000000000, timeout=0x000000016fdfd1a0, sigmask=0x0000000000000000, run_loop_only=NO) at nsterm.m:4964:3
frame #26: 0x00000001003596f8 emacs`ns_select(nfds=0, readfds=0x000000016fdfd24c, writefds=0x000000016fdfd1cc, exceptfds=0x0000000000000000, timeout=0x000000016fdfd1a0, sigmask=0x0000000000000000) at nsterm.m:5016:10
frame #27: 0x00000001002cc594 emacs`wait_reading_process_output(time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=(struct Lisp_Symbol *) $0 = 0x0000000100a840d0, wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5748:18
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71912
; Package
emacs
.
(Tue, 30 Jul 2024 04:08:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 71912 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 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.
I've pushed this to emacs-30.
Frame parameters are handled automatically, and it also fixes weird
non-system tooltip placement on fullscreen frames where the tooltip
opens in another workspace.
Closing.
bug marked as fixed in version 30.1, send any further explanations to
71912 <at> debbugs.gnu.org and Jones Stephen <happyojones <at> gmail.com>
Request was from
Gerd Möllmann <gerd.moellmann <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Tue, 30 Jul 2024 04:09:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71912
; Package
emacs
.
(Sun, 11 Aug 2024 06:51:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 71912 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Forwarded to bug list to keep it informed.
-------------------- Start of forwarded message --------------------
From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Jones Stephen <happyojones <at> gmail.com>
Subject: Re: bug#71912: 30.0.50; Inaccurate window-absolute-pixel-position
Values on macOS After Sleep and During Fullscreen Mode
Date: Sun, 11 Aug 2024 08:41:49 +0200
[Message part 2 (text/plain, inline)]
Jones Stephen <happyojones <at> gmail.com> writes:
> Thank you for the recent patch. I wanted to let you know that after
> using the latest version of Emacs, I found that the fullscreen issue
> has been resolved, which is great news—thank you for that!
>
> However, I’m still encountering an issue with the frame position after
> the system wakes from sleep. Here’s how to reproduce it:
>
> 1. Open Emacs.
> 2. Use a window management tool like Rectangle to position Emacs on one side of the screen.
> 3. Put macOS to sleep.
> 4. Wait for a while, approximately 30 minutes.
> 5. Wake up macOS, enter the login password, and then focus back on Emacs.
>
> At this point, the frame position seems to be incorrect.
I can reproduce this here.
> Interestingly, when I use Rectangle to move Emacs to the other side of
> the screen, the position issue is resolved.
>
> I believe this could be related to missing a system wake notification.
> Perhaps adding something like:
>
> ```swift
> NotificationCenter.default.addObserver(
> self,
> selector: #selector(systemDidWake),
> name: NSWorkspace.didWakeNotification,
> object: nil
> )
> ```
>
> and calling `adjustEmacsFrameRect` in the callback could address this
> issue. Alternatively, calling `adjustEmacsFrameRect` whenever
> `windowDidBecomeKey` is triggered might also work.
>
Indeed, that seems to work, although I find it strage that something
like that is necessary. But what do I know.
Could you please try the attached patch?
[0001-macOS-Wrong-frame-rectangle-after-wake-bug-71912.patch (text/x-patch, attachment)]
[Message part 4 (text/plain, inline)]
-------------------- End of forwarded message --------------------
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71912
; Package
emacs
.
(Sun, 11 Aug 2024 11:27:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 71912 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jones Stephen <happyojones <at> gmail.com> writes:
> Thank you for the patch. I’ve tested it, and it does help, but I
> noticed there’s still a slight issue.
>
> Here’s what I found: if I leave my Mac idle for a while and it enters
> sleep mode, when I wake up the Mac and click to focus on Emacs, the
> frame position sometimes appears to be incorrect. However, if I put
> the Mac to sleep again and then immediately wake it up, the frame
> position is correct when I return to Emacs.
>
> Interestingly, when I moved the `adjustEmacsFrameRect` call to the
> `windowDidBecomeKey` method, the issue was completely resolved. After
> making this adjustment, the frame position remains correct regardless
> of the sleep duration or how the system is woken up.
>
(Please keep the list in CC, I've added it for this reply.)
Thanks. So an a complete patch would look like the attached patch,
right? Could you please confirm?
[0001-macOS-Wrong-frame-rectangle-after-wake-bug-71912.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71912
; Package
emacs
.
(Mon, 12 Aug 2024 03:19:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 71912 <at> debbugs.gnu.org (full text, mbox):
Jones Stephen <happyojones <at> gmail.com> writes:
> Yes, I can confirm that the attached patch resolves the issue.
Pushed to emacs-30. Thanks for testing!
>
> Gerd Möllmann <gerd.moellmann <at> gmail.com> 于2024年8月11日周日 19:25写道:
>
> Jones Stephen <happyojones <at> gmail.com> writes:
>
> > Thank you for the patch. I’ve tested it, and it does help, but I
> > noticed there’s still a slight issue.
> >
> > Here’s what I found: if I leave my Mac idle for a while and it enters
> > sleep mode, when I wake up the Mac and click to focus on Emacs, the
> > frame position sometimes appears to be incorrect. However, if I put
> > the Mac to sleep again and then immediately wake it up, the frame
> > position is correct when I return to Emacs.
> >
> > Interestingly, when I moved the `adjustEmacsFrameRect` call to the
> > `windowDidBecomeKey` method, the issue was completely resolved. After
> > making this adjustment, the frame position remains correct regardless
> > of the sleep duration or how the system is woken up.
> >
>
> (Please keep the list in CC, I've added it for this reply.)
>
> Thanks. So an a complete patch would look like the attached patch,
> right? Could you please confirm?
This bug report was last modified 26 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.