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.

[BrunoQuaresma]

Just reopening it for now until we merge the FE changes into main. Does that sound okay, @defelmnq?

[defelmnq]

@BrunoQuaresma All good yeah , no problem ! ✅

[BrunoQuaresma]

@stirby Unfortunately, it seems we won’t be able to implement the window option as intended. Some browsers don’t support opening a new window with navigation options—or at least, I haven’t found a reliable way to achieve it. A user on Stack Overflow mentioned a related issue with Chrome, and when I tested it on Safari, I encountered the same limitation: it doesn’t allow opening new windows with navigation features.

As a user, I don’t think there’s much difference between opening the app in a new tab versus a new window. We could consider simplifying this by removing the window option altogether or reworking it to have just two choices: tab (opening a new tab) and popup (opening a smaller, focused window). Wdyt?

[stirby]

I see, thanks for investigating this. My mistake for not jumping on this sooner; in the future, let's validate that the FE supports our expected behavior before changing the DB to support it @defelmnq.

The two options (tab, focused window) are sufficient. The new window with navigation is always achievable by pulling out the tab, just some users are unaware that the new tab keybind is possible. Allowing admins to force it with the open_in option would solve the request.

So we should remove the window option for open_in.

[mtojek]

A user on Stack Overflow mentioned a related issue with Chrome, and when I tested it on Safari, I encountered the same limitation: it doesn’t allow opening new windows with navigation features

Perhaps it isn't a huge problem as long as we document the behavior that some browsers do not support it? As a developer I would not be surprised

[BrunoQuaresma]

@mtojek’s suggestion works for me too, but I’d only proceed with it if the window option adds real value. Many users don’t typically read the docs before using the product, so I’d prefer to minimize potential issues stemming from third-party services/software whenever possible.

That said, I’d request help from @defelmnq for the BE changes 💪.

[mtojek]

Another idea @BrunoQuaresma: in browser - could we silently switch the behavior to tab if the window mode is unsupported?

PS. I'd like us to be convinced that discussed all possible options.

[BrunoQuaresma]

Another idea @BrunoQuaresma: in browser - could we silently switch the behavior to tab if the window mode is unsupported?

After some research, it seems there’s no API available to determine how window.open specifications are implemented for a particular browser 😞.

PS. I'd like us to be convinced that discussed all possible options.

Definitely 👍. I’m approaching this from more of a product perspective—if the option doesn’t provide clear value, we should consider removing it to reduce maintenance overhead and potential user confusion.

[defelmnq]

After investigating a bit more (unfortunately late..) indeed :

• tab is the default behavior and will be available - easily - on all browsers.
• slim-window is the only option supported by Chromium-based browser. Works well on all other browsers.
• window is available on some browsers - but not on chromium-based ones.

I would agree with Bruno, as there's two options here :

• either we want to handle the three options but will have to keep track of a compatibility map, and will probably create more confusion than what the feature will provide.
• either we remove window and let users either choose between a new tab or a new slim-window.

cc @stirby @mtojek for the decision - I would personally vote for the removal of window.

While I can work on removing the option on the backend (which should be pretty fast) - Bruno can work on the FE implementation anyway, as the option is already available.

And sorry for the lack of validation here at first.

[mtojek]

for the decision - I would personally vote for the removal of window.

Agree. Let's not elongate this topic anymore, it is a minor feature. The frontend part should be straightforward.