Feedback Issue: Browser-based terminal IDE

[filiptronicek]

Objective

Issue for feedback related to our browser-based terminal IDE.

Related roadmap items:

• Epic: Browser based terminal #11180
• Linear project

Related links

• Form for signing up for the private beta [Gitpod labs] It is available Generally now. See changelog

[erikmd]

Dear Gitpod maintainers,
Thanks to @loujaybee's advice (#2419 (comment)) I was able to test your brand new browser-based Terminal (version 1.0.0 "latest"); here is some feedback/issues reports.

in this first session (using firefox-esr on Debian stable) I was especially interested in testing basic interaction with emacs (which is preinstalled in this ubuntu LTS image 👍)

emacs (2 keybindings issues)

• upside: the interaction is smooth and impressive; I was able to install and run a few packages using MELPA, the emacs menu works well with F10.
• blocking drawbacks: the keybindings C-w (Ctrl+W) and C-q does not work (they are intercepted by firefox to close the tab, and close the browser, which is a bit unfortunate)

additional remarks:

• it appears that C-q is important:
  • both for emacs (it is the standard quoting command to insert control characters (e.g. C-q C-m inserts ^M, that is the 13rd control character, that is the CarriageReturn char))
  • and for the terminal, because it allows to resume a stopped command, e.g. try:

    $ while :; do echo .; sleep 1s; done
    C-s    #(stop)
    C-q    #(resume)

• C-w is a bit less important in emacs, but is still used by default for the cut-to-clipboard shortcut and for saving the buffer to another filename (C-x C-w)
• the C-w issue is reproducible with chromium, and close the tab
• fortunately, the C-q shortcut does not seem to be bound in chromium, so it works as expected in chrome/chromium

conclusion:

• do you think it's feasible to prevent the browser from "seeing these two shortcuts"?
  • if yes, great ✨✨✨
  • otherwise, you could add in the doc a comment suggesting to (1) use Chromium/Chrome to be able to use the C-q keybinding in a tty emacs; and (2) remember to reopen one's browser tab with Ctrl+Shift+T if closed inadvertently.

clipboard handling

Finally, a comment regarding copying/pasting code or logs from/to the browser-based terminal: it's possible to use the browser contextual menu to do so, but due to the default colors, the copied text seems to contain "noise characters"…; sorry I believe I spoke too quick: it appears selecting terminal text and copying is really fine!

Last but not least, thanks a lot for developing this, and congrats for the impressive work!

[jeanphi-baconnais]

Hello 👋
thank's for giving me the terminal option in my Gitpod account. I just quickly tested it, this looks great. I tried a exit command and is it not possible to stop the workspace with this command ? I will test more in detail next weeks

[axonasif]

Hi @jeanphibaconnais, you can use gp stop command instead.

But if you really want to have exit act like gp stop, you could add the following to your dotfiles repo install.sh:

#!/usr/bin/env bash

# If you're using bash as the shell
printf 'alias %s="%s"\n' exit "gp stop" >> "$HOME/.bashrc"

# Or if you want `exit` for all shells
printf '#!/bin/sh\ngp stop\n' > $HOME/.local/bin/exit
chmod +x $HOME/.local/bin/exit

[jeanphi-baconnais]

Hi @axonasif , thanks for your response. Yes of course I know the gp stop command. As it was my first reflex to quit the terminal with the exit command, maybe it would be a behavior by default (or not 😅 )

[erikmd]

Hi all, good news:
I performed new tests to follow-up my experience report,
and got a pretty good workaround (that might be mentioned in Gitpod documentation, maybe :)

For Firefox

• The C-q shortcut can be disabled in the user preferences, and it is then fully seen by the Gitpod terminal.
  • It suffices to open about:config and set browser.quitShortcut.disabled := true.
• The C-w shortcut can't be disabled but the drawback of its outcome can be mitigated by:
  • changing the user preferences to never close the browser if there is only one tab opened with Gitpod,
  • and subsequently type C-S-t (Ctrl+Shift+T) to reopen the Gitpod tab if we mis-closed it.
• Edit: see my next comment.

To this aim, I used this configuration:

Screenshot

Credits: inspired by https://askubuntu.com/a/1401149/851217

For Chromium/Chrome

• The C-w shortcut can be disabled:
  • by installing an extension (e.g. ctrlw, but there are other ones)
  • and configuring its shortcuts so that C-w is a no-op, and C-S-w closes the current tab.
  • remaining drawback w.r.t. Gitpod: the C-w shortcut is not seen by Gitpod (obviously, given it's a no-op :)
• Edit: see my next comment.

To this aim, I used this configuration:

Screenshot

Credits: inspired by https://unix.stackexchange.com/a/621800/297058

[erikmd]

The C-w shortcut can't be disabled

On second thought, I just realize that it's easy to fully fix this aspect, by adding a beforeunload handler in Gitpod's js code.

Additional info

I had done some testing in a webapp project I co-maintain, and just FYI it appears not all ways to add an onbeforeunload are portable across (Firefox, Chrome, Safari); so FWIW, I had ended up with:

window.onbeforeunload = function(e) {e.preventDefault(); return false;}

(that could be "cancelled" with window.onbeforeunload = null;)

[erikmd]

Another issue/wishlist with the Browser Terminal:

The shortcut C-t (Ctrl+T, useful in Emacs as well as in a shell) currently is not caught by Gitpod.
Currently, it always opens a new tab…
Reproduced in Firefox-ESR and Chromium.

Fortunately, the shortcut works if we connect from SSH (not using a browser).

[daniloraisi]

When using XTerm.js, we can define the Font Family that the terminal will use (when creating the terminal instance).

Any possibility to allow us to define a Font Family on the preferences page for the terminal to use?

[axonasif]

@daniloraisi 👋 if you're on firefox, you can configure a custom monospace font from the preferences, this worked for me.

[daniloraisi]

@axonasif I'm using Edge, but it worked the same way. Thanks!

[axonasif]

@daniloraisi awesome!

[ghost]

Thank you for providing a browser-based terminal option.

I'm brand-new to using Gitpod's IDE as an alternative to GitHub Codespaces, and so far I like it and will continue using it.

I'm puzzled by two things I'm seeing:

• When using the browser terminal, the command in .gitpod.yml is not executed. If I run gp validate within a terminal sesion, the debugging image does run my script and set up my database. Also, if I run a browser VS Code session, the script does run and set up the database.
• The browser terminal session takes much longer to start than the browser VS Code session does and it takes even longer to shut down.

(Added) The terminal IDE session takes ~1min to start and 2.5min to 3min to stop.

Please let me know if I should formally open a separate issue. Thanks!

Update 6 Nov:

I created a new terminal IDE workspace and am getting different/better results:

• Startup and shutdown times are short, especially shutdown.
• My setup script specified in .gitpod.yml is being run; I get my .bashrc and .ssh/config copied in to place, but my database is not configured unless I run the script by hand after startup.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.