Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opening a coder_app in a new browser window is awkward #297

Open
stirby opened this issue Oct 15, 2024 · 7 comments
Open

Opening a coder_app in a new browser window is awkward #297

stirby opened this issue Oct 15, 2024 · 7 comments
Assignees

Comments

@stirby
Copy link
Contributor

stirby commented Oct 15, 2024

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"
  ...
}
@defelmnq defelmnq self-assigned this Nov 8, 2024
@matifali
Copy link
Member

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
Copy link

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

@matifali
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

mtojek commented Dec 2, 2024

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
Copy link
Contributor

defelmnq commented Dec 2, 2024

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
Copy link
Member

matifali commented Dec 2, 2024

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.

defelmnq added a commit to coder/coder that referenced this issue Jan 3, 2025
This PR is the coder/coder part of [the open_in parameter
issue](coder/terraform-provider-coder#297)
aiming to add a new optional parameter to choose how to open modules.

This PR is heavily linked [to this
PR](coder/terraform-provider-coder#321).

ℹ️ For now, some integrations tests can not be pushed as it requires a
release on the terraform-provider repo.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants