Opening a coder_app in a new browser window is awkward

[stirby]

Problem statement

Currently, coder_apps open a slimmed down browser without navigation buttons or tabs. While the slim window maximizes display space for the app and makes it feel like a local process, apps like the filebrowser suffer from not having forward/back arrows.

You can open the apps in a new tab then pull them into a new window; but, not all users are aware of this shortcut. We're also missing the Shift+Click keybind to open a fresh browser window.

Solution proposal

We add a new property to coder_app like open_in with options to specify the default method of opening the app. We should also achieve parody with chrome keybindings. This attribute would set the default on-click behavior:

Option	Action	Chrome Keybind	Default Coder Keybind
tab	Opens in a new tab in the same browser window	ctrl+click	ctrl+click
window	Opens a fresh browser window with navigation options	shift+click	shift+click (not present today)
slim-window (default)	Opens a window without tabs or navigation (currently default)	NA	click

For example, the following would open the app in a full new window on regular click or shift+click, and a new tab on ctrl+click.

resource "coder_app" "code-server" {
  agent_id     = coder_agent.dev.id
  slug         = "code-server"
  display_name = "VS Code"
  open_in      = "window"
  ...
}

[matifali]

Instead of doing it in the provider, I propose adding it to User settings. coder_app preference and use that to open all coderr_apps for that user in the tab or new window.

cc: @coder/pms?

[aaronlehmann]

Some apps really need nav buttons. IMO this is something where at least the defaults should be declared at the app level.

[matifali]

Some apps really need nav buttons. IMO this is something where at least the defaults should be declared at the app level.

Yes for choosing a full window vs a slim window. I agree but adding tab vs window could be a user option.

[defelmnq]

As I investigated this ticket and started to work on it, here are a few things.

Comments

• Would we also like to add this logic to web_terminal ? This one seems to be a bit specific and not working using coder modules.

• I tried to check all our modules and want to be sure , is it the solution that makes the most sense ? From what I've been able to see in github.com/coder/modules , at least a good part of our modules are native ones (vscode, cursor, jetbrains...) and do not open a new window. I just want to be sure this is the correct solution.

Steps to implement

Considering that want to implement the solution described in the ticket - here are the steps :

1. The first step would be to modify the DB - specially the workspace_apps table to add a new column open_in. The field will use default value slim-window for all the apps in order to keep the current behavior and be transparent.

2. Propagate this option up to the frontend - by doing so the frontend use the value from the DB.

3. Modify terraform-provider to implement this value as optional with default so the values inserted into the DB are now the one from the provider.

4. Finally, modify some modules (if we want to) to adopt the new behavior.

cc @dannykopping for visibility.

[mtojek]

Would we also like to add this logic to web_terminal ? This one seems to be a bit specific and not working using coder modules.

Er... maybe as a follow-up item? Let's focus first on this issue.

at least a good part of our modules are native ones (vscode, cursor, jetbrains...) and do not open a new window. I just want to be sure this is the correct solution.

Is it about validation? so that admin can't really configure the window behavior for vscode and others?

[defelmnq]

Er... maybe as a follow-up item? Let's focus first on this issue.

Agree - thanks. I'll open a second issue once this one is validated so we keep track of it.

Is it about validation? so that admin can't really configure the window behavior for vscode and others?

My concern is more about adding an option to the templates - I feel like only a small percentage of our templates are browser-based - the other ones opening the native software. This option applies only to the browser-based modules. So if we add the option to the modules, it means it will be ignored for all the non browser-based modules. Is it fine ?

[matifali]

So if we add the option to the modules, it means it will be ignored for all the non-browser-based modules. Is it fine?

For no browser-based modules, we use external = true with url which is usually a URI to open some native software on the client machine. But It can also be an http/https external URL outside of Coder and in that case,e we can apply these new options.