Skip to content

Escape key caused losing focus out of editor on Vivaldi #638

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

Closed
lamnguyenx opened this issue May 3, 2019 · 9 comments
Closed

Escape key caused losing focus out of editor on Vivaldi #638

lamnguyenx opened this issue May 3, 2019 · 9 comments
Labels
bug Something isn't working

Comments

@lamnguyenx
Copy link

  • code-server 1.939-vsc1.33.1
  • OS Version: Ubuntu 16.04 (Host) - Windows 8 Server (Local)
  • Browser: Vivaldi 1.24

Description

I usually hit Escape when editing (e.g: cancel intellisense suggestion). It's working normally on Chrome. However, on Vivaldi (which lets you change browser's color, reduce tab's size and hide address bar for less distraction), Escape key constantly cause losing focus out of the editor. I had to press Ctrl + 1 to refocus every time.

Steps to Reproduce

  1. Start Vivaldi and open code-server.
  2. Edit any file and press Escape, then try typing any characters.
@lamnguyenx lamnguyenx added the bug Something isn't working label May 3, 2019
@lamnguyenx lamnguyenx changed the title Escape key caused losing focus on the editor on V Escape key caused losing focus out of editor on Vivaldi May 3, 2019
@nhooyr
Copy link
Contributor

nhooyr commented Jan 28, 2020

Not really sure what's going on. If anyone figures out, please let us know.

@KaKi87
Copy link

KaKi87 commented Jun 27, 2024

Hello,
I'm experiencing the same issue.
Thanks

@wh0am1-dev
Copy link

wh0am1-dev commented Apr 14, 2025

Same here. For reference, I think code-server should call preventDefault() or stopPropagation() on keyboard events for this to be fixed:

I've tried adapting the user-script from the Vivaldi Forums link above, but it didn't work:

// ==UserScript==
// @name         code-server-handle-esc.user.js
// @version      0.1
// @description  Support Esc key in code-server by preventing propagation Vivaldi blur event.
// @match        http://*/*
// @match        https://*/*
// ==/UserScript==

// https://forum.vivaldi.net/topic/73501/unmapped-esc-key-changes-focus/16

;(function () {
  function addEscListener(e) {
    window.removeEventListener('load', addEscListener)
    const monaco = document.querySelector('#workbench\\.parts\\.editor')
    if (monaco) {
      const textarea = monaco.querySelector('textarea')
      textarea.addEventListener('keydown', e => {
        if (e.key === 'Escape') e.stopPropagation()
      })
    }
  }
  window.addEventListener('load', addEscListener)
})()

@code-asher
Copy link
Member

We just wrap VS Code so it sounds likely it will need to be fixed there: https://github.com/microsoft/vscode

@wh0am1-dev
Copy link

@code-asher, I disagree. VSCode doesn't run within a browser, but rather it's own native wrapper window. Since this project wraps VSCode to make it accessible within any browser, it's on this project to prevent browser-specific default behaviors when needed.

@code-asher
Copy link
Member

code-asher commented Apr 15, 2025

VS Code contains both an Electron and web version. We use the web version, as does GitHub Codespaces (and Gitpod).

You can run VS Code's web version directly without our wrapper using code serve-web.

Edit to add: we do maintain some patches to make the web version work a bit more nicely for self-hosting use cases. However, we try not to patch bugs and prefer they go upstream, where they can benefit everyone using the web version of VS Code (Codespaces, Gitpod, etc).

If they refuse to fix/add something, we can talk about patching it here though.

@wh0am1-dev
Copy link

All right, understood, will open an issue there. Thanks @code-asher !

@KaKi87
Copy link

KaKi87 commented Apr 15, 2025

If they refuse to fix/add something, we can talk about patching it here though.

Would you add microsoft/vscode#77363 then ?

@code-asher
Copy link
Member

@KaKi87 It looks like they are still open to the change if someone opens a new PR?

Bug fixes are one thing, but I would hesitate to maintain features that change this many lines. If we think there are unlikely to be conflicts moving forward though I think we could consider it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants