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

Using shortcuts inside browser #112

Closed
cyalide opened this issue Mar 7, 2019 · 21 comments
Closed

Using shortcuts inside browser #112

cyalide opened this issue Mar 7, 2019 · 21 comments

Comments

@cyalide
Copy link

cyalide commented Mar 7, 2019

Description

Some VSC shortcuts do not work because they are reserved for browser-specific actions.
For instance, Strg + N usually opens a new file in VSC, but is reserved by various browsers for creating a new tab or window.

Do you have a plan for improving this? Of course every shortcut is accessible by the command palette, and commands which are unaccessible by the default shortcuts can be reconfigured to be accessible by other shortcuts, but this would require everyone who wants to give code-server a try to configure his instance first before being able to use it productively, and having powerful editing capabilities without the need for extensive configuration is one of VS Code's key features.

Related Issues

@kylecarbs
Copy link
Member

We’ll be providing some local-apps soon. Unfortunately, we can’t override keybinds like ctrl+n. It’s a browser restriction.

@hbjydev
Copy link

hbjydev commented Mar 8, 2019

Not strictly true. There is a way to do it, but it's kind of a local-app hybrid. If you're on Chrome (sorry Firefox users!) you can go to Menu > More Tools > Create Shortcut... and just tick "Open As Window" when you make it. Then, just use that to work with Coder and all your ctrl+? shortcuts will work.
It is a browser restriction, although there is a code-side workaround to that too. When you listen for each event, you can put event.preventDefault();. That'll stop any default handling from occurring, including the browser trying to process the keybinds iirc.

@cyalide
Copy link
Author

cyalide commented Mar 8, 2019

When you listen for each event, you can put event.preventDefault();. That'll stop any default handling from occurring, including the browser trying to process the keybinds iirc.
I think it could be very useful to provide such a behaviour as an additional option which could be activated and deactivated using some kind of trigger, for example using the command palette or a specific keybinding.

@hbjydev
Copy link

hbjydev commented Mar 8, 2019

So almost like switching between a capture hotkeys and don't capture hotkeys state?

@cyalide
Copy link
Author

cyalide commented Mar 8, 2019

@haydennyyy Yes, exactly.

@hbjydev
Copy link

hbjydev commented Mar 8, 2019

@cyalide I dunno, man. This seems like a lot of unnecessary modification to VSCode herself, especially when desktop apps are in the pipeline...

@kylecarbs
Copy link
Member

Interesting. We can experiment with this, but the apps are on the way.

@hbjydev
Copy link

hbjydev commented Mar 8, 2019

@kylecarbs https://stackoverflow.com/a/7296303 There's a little brief tutorial on how it could be done.

@kylecarbs
Copy link
Member

We already listen for keybindings and override what we can. When opening in a window, if the browser allows for those keys to be overridden they actually should be.

@nhooyr
Copy link
Contributor

nhooyr commented Mar 8, 2019

Closing as this issue as wontfix, cause we really can't.

Electron app is being tracked at #142

@w0utert
Copy link

w0utert commented May 26, 2020

I know this issue is closed as wontfix and I understand why, but I'm wondering whether it would be possible to have the option to at least remap shortcuts that involve modifiers automatically so they don't conflict with browser keybindings. For example remap all shortcuts involving Ctrl to Ctrl-Alt or Ctrl-Cmd or something like that. This way they would be very unlikely to conflict with any browser shortcuts, which almost exclusively use a single modifier.

I appreciate the sshcode efforts, but for me it's a big plus to be able to access the same running code-server instance from any machine that has Chrome on it, without having to install anything else, synchronize source code and settings, etc.

@nhooyr nhooyr reopened this May 26, 2020
@nhooyr
Copy link
Contributor

nhooyr commented May 26, 2020

Let's see what we can do. @code-asher

@code-asher
Copy link
Member

code-asher commented May 26, 2020

@w0utert is there a reason you can't customize the keybindings to achieve this?

fwiw, here's a comment on this from one of the VS Code developers (first paragraph): https://github.com/MicrosoftDocs/vsonline/issues/465#issuecomment-625338703

@nhooyr
Copy link
Contributor

nhooyr commented May 27, 2020

He wants to do it automatically. So anyone key bind involving Ctrl now needs Ctrl+Cmd.

@code-asher
Copy link
Member

Yup, but why not simply change the problematic keys via the keybinding settings? It only needs to be done once and will be consistent for all sessions and states no matter how you access code-server (for example fullscreen vs not fullscreen or PWA vs not PWA or even code-server vs local VS Code if you sync settings) which is good news for muscle memory.

If the machine has Chrome another strategy is to click the icon next to the URL bar and use code-server as a PWA which should eliminate keybinding issues. As mentioned fullscreen is another strategy but that's not always viable imo.

@nhooyr
Copy link
Contributor

nhooyr commented May 27, 2020

Yup, but why not simply change the problematic keys via the keybinding settings? It only needs to be done once and will be consistent for all sessions and states no matter how you access code-server (for example fullscreen vs not fullscreen or PWA vs not PWA or even code-server vs local VS Code if you sync settings) which is good news for muscle memory.

Wouldn't that be really annoying? There are likely a ton of key binds and he might be using code-server on multiple new VMs constantly.

@code-asher
Copy link
Member

code-asher commented May 27, 2020

In that case wouldn't you persist your data directory or already have some kind of automation in place for that? Otherwise you'd lose more than just keybindings; you'd also lose your extensions, extension settings, VS Code settings, history, and language settings at the very least.

Also wouldn't it be better to have keybindings that are guaranteed to be consistent rather than have potentially different behavior depending on whether you've accessed code-server as a PWA or through a regular browser tab or with fullscreen or not fullscreen or Firefox or Chrome or another browser?

It also seems like an odd workaround when there's a superior solution (PWA).

I'm not sure what the full list of keybindings are but off the top of my head we have at least (ctrl versions):
ctrl+w
ctrl+n
ctrl+shift+n
ctrl+t
ctrl+shift+t (on Chrome)
ctrl+shift+p (on Firefox)

In terms of implementation it seems easy enough for us to detect the browser + display mode and set the defaults accordingly. I think we'd need a bit more work to dynamically swap the defaults based on whether you're currently in fullscreen or not (since I think it reads the defaults once on page load) but I don't imagine it'd be very hard.

@code-asher
Copy link
Member

Couple more:
ctrl+tab
ctrl+shift+tab

@nhooyr
Copy link
Contributor

nhooyr commented May 27, 2020

I think most users just aren't aware of the PWA and how it works.

Opened #1726

And we should show a popup #1599

@w0utert
Copy link

w0utert commented May 27, 2020

@w0utert is there a reason you can't customize the keybindings to achieve this?

Obviously that's an option. but as @nhooyr pointed out it's a huge inconvenience as I also use the same workspace locally, and have several other unrelated workspaces that I never access through code-server. I would rather keep those unaffected.

But I think my problem is already solved by switching to PWA mode, which I indeed was not aware of, which is great, thanks! I think @nhooyr's suggestion to add a pop-up and a FAQ entry are both very good ideas.

@nhooyr
Copy link
Contributor

nhooyr commented Jun 3, 2020

With those two other issues I think we can safely close this.

@nhooyr nhooyr closed this as completed Jun 3, 2020
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

6 participants