Instead of waiting unconditionally 250 ms after sending the
credentials to fit the terminal size, wait until the server responds
'OK' to accommodate slower backends or high-latency connections.
As we want to ensure that the browser had some time to actually paint
the DOM we cannot just trigger the fit function directly. Rather chain
requestAnimationFrame [0] twice, first will be called before the
current frame, where xterm.js might not have been rendered yet, and
then another time before the next frame, to show terminal content as
soon as possible but as late as necessary.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[TL: reword and expand commit message & add reference to MDN]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
and upgrade fit-addon to 0.9.0 and webgl-addon to 0.17.0 to be
compatible.
We have to slightly adapt the Makefile to download the correct files, as
xtermjs now uses a different package naming:
xterm -> @xterm/xterm
xterm-addon-* -> @xterm/addon-*
which also changes the extracted file names from xterm-addon-*.js to
addon-*.js so adapt them in the index templates.
This also means we have to change the lintian override paths for those.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
since under certain circumstances (e.g. using safari < 16) the addon
constructor already throws an exception, not only the loading later.
To allow falling back to the canvas renderer, move it into the try
block after WebGL detection.
This should fix the xterm.js console on Apple's iOS.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
With the new WebGL renderer, chrome/chromium has buggy software
support for emulating this (see [0]), so we have to detect that
manually and prevent loading the add-on. This fixes the issue that on
chrome without HW-support, it would not always render every character.
Firefox does not have support for a software renderer and the
loading/detection throws an exception, falling back to the default
renderer.
0: https://github.com/xtermjs/xterm.js/issues/4574
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Avoids that we need to bump all frontends with updated dependencies
and then add them to the proxmox-termproxy's Breaks info.
We can loosen this dependency on the next major release, or when all
users switch to the respective ones (with a versioned Break!).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We should have never added a upstream repackage and some custom tools
in the same source package, let alone binary package. Finally resolve
that tech debt and do a split.
This commit does a bit more than I'd like at once, but it's really not
trivial to make a clean split while keeping all sanely buildable in
multiple commits.
What roughly happens is:
- two complete separate source packages
- one for xterm.js, we keep this purely to the xterm.js and our
local additions and modifications that are relevant directly to
xterm.js itself
- one for termproxy, where only the rust-based tool is shipped.
This also reduces churn, as the termproxy doesn't sees lots of
updates, so no point in building it on every xterm.js update.
- drop debcargo, which while great for library source code packages
for build dependencies, is just a PITA for binary packages
shipping actual compiled rust code, it adds almost nothing there
but provides lots of special handling to get the correct result.
- rename `termproxy` to `proxmox-termproxy` but keep a backward
compat link for now, termproxy is way to general a name.
Maybe we should also move this away from /bin in general, into the
/lib/<arch-qualifier>/proxmox/ directory like we do for
proxmox-backup.
- clean ups all over the place
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
