I've observed this behavior when:

• the DISPLAY variable is set (eg. when using ssh -X to a remote system)
• the remote system does not have a GUI web browser installed

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 by ssh -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 set DISPLAY 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.