-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
Comments
We’ll be providing some local-apps soon. Unfortunately, we can’t override keybinds like ctrl+n. It’s a browser restriction. |
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. |
|
So almost like switching between a capture hotkeys and don't capture hotkeys state? |
@haydennyyy Yes, exactly. |
@cyalide I dunno, man. This seems like a lot of unnecessary modification to VSCode herself, especially when desktop apps are in the pipeline... |
Interesting. We can experiment with this, but the apps are on the way. |
@kylecarbs https://stackoverflow.com/a/7296303 There's a little brief tutorial on how it could be done. |
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. |
Closing as this issue as wontfix, cause we really can't. Electron app is being tracked at #142 |
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. |
Let's see what we can do. @code-asher |
@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 |
He wants to do it automatically. So anyone key bind involving |
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. |
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. |
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 ( 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. |
Couple more: |
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. |
With those two other issues I think we can safely close this. |
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
The text was updated successfully, but these errors were encountered: