Giters

PerBothner / DomTerm

DOM/JavaScript-based terminal-emulator/console

Home Page:https://domterm.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Hangs on (almost) any image in browser

csik opened this issue · comments

commented

I'm running DomTerm in a docker image, rendering in a browser (osx). HTML escaping works, but anything graphical hangs in the browser, with the exception of hcat which works with svgs. Sixel and gnuplot appear to go into a newline and the cursor blinks but is unresponsive. Maplotlib is the same, though it did seem to create a black rectangle and would recover the prompt with a ctrl-c. This is happening with both Firefox and Chrome.

Below is example of a verbose log from trying to do a gnuplot.

I'm assuming these graphic features are supposed to work on browsers. Any tips on what I should be looking for, or how I can provide better debugging info? Thanks, having used a few browser terminals in the past, all of which are now abandoned (!) I know this is hard work.

'''
domterm terminal server 2.9.0 (git describe: 2.1-440-g0236058)
Copyright 2021 Per Bothner and others
Using Libwebsockets 4.1.99-v4.1.0-353-gbdc0657e
Reading settings file: /root/.config/domterm/settings.ini
connecting to server socket '/root/.domterm/default.socket': No such file or directory
LWS: 4.1.99-v4.1.0-353-gbdc0657e, loglevel 7
NET CLI SRV H1 H2 WS IPv6-absent
++ [wsi|0|pipe] (1)
++ [vh|0|netlink] (1)
++ [vh|1|default||8089] (2)
lws_socket_bind: nowsi: source ads 0.0.0.0
++ [wsi|1|listen|default||8089] (2)
creating server socket: '/root/.domterm/default.socket'
++ [wsisrv|0|adopted] (1)
lws_role_call_adoption_bind: falling back to raw file role bind
lws_role_call_adoption_bind: falling back to raw file role bind
initial html file: '/root/.domterm/default.html'
initial html redirects to: 'http://localhost:8089/no-frames.html'
Server start on port 8089. You can browse http://localhost:8089/
++ [wsisrv|1|adopted] (2)
lws_role_call_adoption_bind: falling back to raw file role bind
lws_role_call_adoption_bind: falling back to raw file role bind
callback_ssh_stdin reason 27
callback_ssh_stdin reason 71
rops_handle_POLLIN_netlink: route list size 1
rops_handle_POLLIN_netlink: route list size 2
rops_handle_POLLIN_netlink: route list size 3
rops_handle_POLLIN_netlink: route list size 4
rops_handle_POLLIN_netlink: route list size 5
callback_ssh_stdin reason 71
++ [wsisrv|2|adopted] (3)
callback_ssh_stdin reason 71
++ [wsisrv|3|adopted] (4)
callback_ssh_stdin reason 71
++ [wsisrv|4|adopted] (5)
++ [wsisrv|5|adopted] (6)
++ [wsisrv|6|adopted] (7)
callback_ssh_stdin reason 71
++ [wsisrv|7|adopted] (8)
callback_ssh_stdin reason 71
++ [wsisrv|8|adopted] (9)
callback_ssh_stdin reason 71
callback_tty FILTER_PROTOCOL_CONNECTION
tty/CALLBACK_ESTABLISHED (null) client:(nil)
init_tclient_struct conn#-1
++ [wsisrv|9|adopted] (10)
lws_role_call_adoption_bind: falling back to raw file role bind
lws_role_call_adoption_bind: falling back to raw file role bind
link_command wsi:0x55cf62406b80 tclient:0x55cf62407060 pclient:0x55cf6240d7f0
set_connection_number 0x55cf62407060 to 1
client connected from 172.17.0.1 (172.17.0.1), #: 1
callback_ssh_stdin reason 71
run_command /bin/bash after fork child:17654
starting application: /bin/bash session:1 pid:17654 pty:16
run_command /bin/bash after fork child:0
-- [wsisrv|5|adopted] (9) 5.031s
-- [wsisrv|2|adopted] (8) 5.132s
-- [wsisrv|3|adopted] (7) 5.039s
-- [wsisrv|4|adopted] (6) 5.041s
-- [wsisrv|6|adopted] (5) 5.045s
-- [wsisrv|7|adopted] (4) 5.041s
-handle_input write start:0 w:1
-handle_input write start:0 w:1
-handle_input write start:0 w:1
-handle_input write start:0 w:1
'''

commented

I'm seeing problems with images too. Oops. I recently changed the escape-sequence parser to work on bytes directly, and that might be related. Working on it.

commented

It seems like it might be a problem in how flow control is done. A big image sent over multuiple "chunks" isn't acknowledged until it is all sent, by which time the sender is paused. If it is what I think it is, it is conceptually a simple fix, but it's not a completely trivial fix.

commented

Thank you so much for looking into this. This is not my area but if there's anything I can help with on the testing side, let me know.

commented

Could you re-pull and try again?

commented

  1. A cat of sixel works perfectly, though after the active bottom line of the cursor is %90 hidden under the bottom of the window with each newline.
    image

  2. GNUplot looks perfect. Cursor keeps working.

  3. Matplotlib generates the following:

`
plt.show()

Inserted invalid HTML starting here:

<rdf:RDF xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
cc:Work
<dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
dc:date2021-03-31T21:41:17.254209</dc:date>
dc:formatimage/svg+xml</dc:format>
dc:creator
cc:Agent
dc:titleMatplotlib v3.4.0, https://matplotlib.org/</dc:title>
</cc:Agent>
</dc:creator>
</cc:Work>
</rdf:RDF>

snip__
`

commented

I did notice a problem with html output. For example domterm help new works but plain domterm help fails. That might be related to the problem you mention. Haven't figured that out yet, but it looks like DomTerm gets confused in terms of how many lines there are.

commented

Sorry for the red herring -- the cursor behaves normally if the window is at the width of the sixel or greater; it only tries to hide if the sixel is wider than the window, so I think this really isn't a serious issue at all for most users. Printing as html from print_html in python seems to work:
image

At this point, only the matplotlib seems genuinely broken. I'll close this issue, please advise if you'd like me to open one specifically for matplotlib. And thank you very much for the quick fix!