GNU bug report logs -
#65332
29.1; browse-url calls pgtk-backend-display-class, which errors when window-system is nil
Previous Next
Full log
View this message in rfc822 format
"Trent W. Buck" <trentbuck <at> gmail.com> writes:
> Minimum recipe to reproduce:
>
> 1. Get emacs with pgtk, start daemon, connect to it from a tty frame:
>
> twb <at> hera[Desktop]$ emacs-pgtk --version
> GNU Emacs 29.1
> Copyright (C) 2023 Free Software Foundation, Inc.
> GNU Emacs comes with ABSOLUTELY NO WARRANTY.
> You may redistribute copies of GNU Emacs
> under the terms of the GNU General Public License.
> For more information about these matters, see the file named COPYING.
>
> twb <at> hera[Desktop]$ emacs-pgtk --quick --daemon
> Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a
> display connection is closed. The problem is especially difficult to fix,
> such that Emacs on Wayland with multiple displays is unlikely ever to be able
> to survive disconnects.
> Starting Emacs daemon.
>
> twb <at> hera[Desktop]$ emacsclient --create-frame --tty
>
> 2. M-x browse url RET https://example.com RET
>
> Get this error:
>
> Frames are not in use or not initialized
>
> 3. Explicitly setting browse-url-browser-function to eww-browse-url does not help.
>
> With toggle-debug-on-error, the backtrace I got during normal usage was:
>
> Debugger entered--Lisp error: (error "Frames are not in use or not initialized")
> browse-url("http://ix.io/4DCN")
> find-file-at-point()
> ido-file-internal(selected-window)
> ido-find-file()
> funcall-interactively(ido-find-file)
> command-execute(ido-find-file)
>
> The problem is it's calling (pgtk-backend-display-class) even when the current frame isn't a GTK frame, I think?
>
> ELISP> (browse-url "https://example.com")
> *** Eval error *** Frames are not in use or not initialized
> ELISP> (w3m-browse-url "https://example.com")
> nil
> ELISP> browse-url-browser-function
> w3m-browse-url
> ELISP> (pgtk-backend-display-class)
> *** Eval error *** Frames are not in use or not initialized
> ELISP> window-system
> nil
> ELISP> (frame-parameter nil 'display)
> ":0"
> ELISP> (getenv "DISPLAY")
> ":0"
> ELISP> (getenv "WAYLAND_DISPLAY")
> "wayland-0"
Your analysis of the problem is correct.
But to correct it, we need to know what display our users expect the
browser window to open in under such a situation?
This bug report was last modified 1 year and 305 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.