Cockpit: opening vi / vim in terminal takes a long time and htop is rendered wrong

[t3chn0m4g3]

Cockpit version: 188 on Debian (Sid)
OS: Windows 10
Page: Terminal

Opnening vi in terminal results in a very long loading time. During this time (10-20 seconds) the browser (Google Chrome Version 73.0.3683.67 beta (64-Bit)) becomes unresponsive. Afterwards everything works fine, unless the browser window gets resized which again results in unresponsiveness of 10-20 seconds.

Interesting thing, whenever vi is called it results in ...

Mar 08 16:20:02 electricalsculpture systemd[1]: systemd-timedated.service: Succeeded.
Mar 08 16:20:03 electricalsculpture dbus-daemon[509]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.106' (uid=1000 pid=8392 comm="cockpit-bridge ")
Mar 08 16:20:03 electricalsculpture systemd[1]: Starting Time & Date Service...
Mar 08 16:20:03 electricalsculpture dbus-daemon[509]: [system] Successfully activated service 'org.freedesktop.timedate1'
Mar 08 16:20:03 electricalsculpture systemd[1]: Started Time & Date Service.
Mar 08 16:20:52 electricalsculpture systemd[1]: systemd-timedated.service: Succeeded.
Mar 08 16:20:54 electricalsculpture dbus-daemon[509]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.106' (uid=1000 pid=8392 comm="cockpit-bridge ")
Mar 08 16:20:54 electricalsculpture systemd[1]: Starting Time & Date Service...
Mar 08 16:20:54 electricalsculpture dbus-daemon[509]: [system] Successfully activated service 'org.freedesktop.timedate1'
Mar 08 16:20:54 electricalsculpture systemd[1]: Started Time & Date Service.

Reproduction:

1. Login to Cockpit
2. Use Terminal page
3. open vi in terminal
4. optionally resize the browser window once vi loaded, results in the same effect.
   BTW, nano works just fine.

[marusak]

I looked into this and here are some finds:
1) This is definitely related to the fact we are using accessibility mode (screenreader support). If I turn off this mode it works immediately
2) It is related to the size of window. On smaller window size it works faster, on bigger screen works slower
3) Opening nonexistent or empty file is much slower than opening existing file. Opening empty file takes ~4s, opening file with 1 line takes ~3.8s, opening file with 2 lines takes ~3.5s, 10 lines takes ~2.3s, opening file with more than 20 lines is immediate (out of 40 visible lines). On smaller screen it works proportionally. If I fit on screen only 20 lines and open empty file it is immediate, if I fit 30 lines on screen and open empty file it takes around those 2 seconds.

It seems that every empty line in vim sends something that xterm.js parses for accessibility mode. This seems most likely like an xterm.js issue. Will try to gather more info and open issue there.

[t3chn0m4g3]

@marusak Thank you for taking this on!

[leomoty]

Also, opening a "folder", results in ~30s for me. I tried to open the wrong file (well, folder) and found the same issue.

[mvollmer]

Note that according to #11369, things are not only slow, but are actually rendered incorrectly.

[PeterFalken]

@marusak, is there a way to toggle accessibility mode (screenreader support).
If it is, would it be possible for it to be toggled by a control on the UI? And maybe set the default value on the /etc/cockpit/cockpit.conf file. That way if it is decided to keep the accessibility mode turned on by default, this can be overridden by this configuration.

[martinpitt]

cockpit.conf does not work, this isn't the place to store user preferences. But it could be stored in the cookie just like the theme. That said, this is an "unbreak my UI" option, and in the long run this should be fixed to "just work". But that will most likely at least involve an xterm.js bug report and fix.

[PeterFalken]

Storing it on the cookie makes sense. We'll just have to wait for upstream fix from xterm.js

[t3chn0m4g3]

Is there a corresponding upstream issue we can link or should we open one?

[leomoty]

@marusak opened this one: https://github.com/xtermjs/xterm.js/issues/1965

[PeterFalken]

@marusak
What would be a temporary way to disable the screenReaderMode for XTermJS?
On your tests, you mentioned that you turned it off and the response was immediate.
Can you share how you managed to turn it off?

Regards,
Peter

[marusak]

Can you share how you managed to turn it off?

I build my own cockpit as described in HACKING. And the only change that is needed in the code it to drop this line (or set it to false).

[t3chn0m4g3]

I have been using neovim for a couple of days now which is working flawlessly with the new terminal.

[waclaw66]

Refreshing whole terminal screen (e.g. start of mc) is incredible slow, it takes 5-10s in version 194.
It was immediate in previous versions.

[PeterFalken]

Looking at the thread of the xtermjs project where we reported the issue. It seems that they provided a fix a day ago, but still recommend that a way is provided for the ScreenReader functionality to be disabled/enabled.

[waclaw66]

Any progress in this? Couldn't be the screenReaderMode set by configuration? The laggy terminal is annoying. Thanks.

[leomoty]

It seems that xterm solved that in 3.14, but @marusak is waiting to update to xterm 4.0 directly: https://github.com/cockpit-project/cockpit/pull/12736

So I guess we'll have to wait a bit longer.

[marusak]

It seems that xterm solved that in 3.14, but @marusak is waiting to update to xterm 4.0 directly: #12736

Indeed. 3.14 has breaking changes, so does 4.0 compared to 3.14, so I thought that I just may do this jump and have the new 4.0 version. Currently I am getting close with https://github.com/patternfly/patternfly-react/pull/3030

[marusak]

Should be fixed in #12948

[PeterFalken]

@marusak, It seems that #12948 has conflicts and wasn't applied. Looking forward to this enhancement.

[marusak]

#12948 finally landed. Today we are doing a new release 212 and it should be fixed. I just tested it and could not reproduce. Please reopen if it still persists with 212.

[t3chn0m4g3]

@marusak Thank you very much for tracking this and all the great work you put in Cockpit.

Very much appreciated!