-
-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Opening URLs can freeze terminal (X11 but no GUI browser) #1475
Labels
Comments
neiljp
changed the title
Opening URLs can freeze terminal (X11 but no GUI browser?)
Opening URLs can freeze terminal (X11 but no GUI browser)
Mar 10, 2024
18 tasks
Sushmey
added a commit
to Sushmey/zulip-terminal
that referenced
this issue
Apr 15, 2024
Temporarily unsetting TERM environ so text-browsers aren't detected. This results in an exception which displays an error for text-browsers. Fixes zulip#1475.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've observed this behavior when:
DISPLAY
variable is set (eg. when usingssh -X
to a remote system)Currently our URL-handling function has an explicit check for
DISPLAY
, and avoids opening the URL if it does not find it (on Linux), with an error message.With
DISPLAY
set, for a terminal in a GUI (or byssh -X
), we allow the python webbrowser module to find a browser. In my case it only finds a text-only browser installed (links), which it attempts to run in the same terminal, which likely interacts badly with the urwid loop.A possible way to reproduce this would be to run on a remote environment or one with no GUI browsers installed, and either connect using something like
ssh -X
(X forwarding), or explicitly setDISPLAY
to trick the detection into thinking a GUI is present.One possible solution is to manually stop and start the urwid loop, as occurs in #1394. However, currently I don't see a straightforward (documented) way using
webbrowser
to determine if it is a GUI or text web-browser. That means that a challenge with this approach, if it resolves the issue, is that for users within a GUI, this may leaves the ZT UI unusable until the browser returns/closes. This wasn't an issue for #1394, as the assumption is one is composing separately, and in most cases the editor temporarily replaces the ZT window.The text was updated successfully, but these errors were encountered: