Escape key caught by Vimium #499

Closed
ripdajacker opened this Issue Mar 6, 2012 · 26 comments

Comments

Projects
None yet

Vimium catches the keystroke for escape, even when out of input mode. The easiest way to show this is on Facebook chat, where you in the old version could press escape twice and close the chat.

Collaborator

int3 commented Mar 6, 2012

Hm, in the old version pressing esc once would close the chat window, and I often found myself not wanting that. I agree that never having the window close is also a bit of an annoyance though. Perhaps we should create some sort of pass-through mode for this.

What about , Esc - it would be similar to Vim passthrough mode ?

How about making a mapping of sorts? I found myself setting "unmap " to try to fix this, planning on using <C-[> to exit out of input mode.

Of course, it didn't work; but this was intuitive for me.

+1 For this bugfix, since it breaks text editor selection reduction such as in CodeMirror Sublime

God this is annoying, have run into it multiple times now. Would be cool if it could be fixed, without http://stackoverflow.com/questions/12927752/keydown-keyup-events-not-detecting-the-escape-key-being-pressed-on-input-text-fi I would've been lost.

Collaborator

smblott-github commented Jan 6, 2015

What behaviour would you like to see from Esc?

Vimium does not allow propagation of any webpage's Escape keyup bound
events. If you are not engaged in a Vimium activity(like f for find link)
then there it only seems to inhibit the abilities of the user.

On Tue, Jan 6, 2015 at 8:18 AM, Stephen Blott notifications@github.com
wrote:

What behaviour would you like to see from Esc?


Reply to this email directly or view it on GitHub
#499 (comment).

Collaborator

smblott-github commented Jan 6, 2015

Vimium does not allow propagation of any webpage's Escape keyup bound
events

Really?

Test:

watch = (type) ->
  document.addEventListener type, (event) ->
    para = document.createElement "p"
    para.innerHTML = type
    document.body.appendChild para

watch "keydown"
watch "keypress"
watch "keyup"

Running here. Looks the same to me with or without Vimium.

To repeat...

What behaviour would you like to see from Esc?

Perhaps it would be helpful if you could point us to a specific page, so we all have a specific use case in mind.

I'm looking at your demo right now, this is specifically a case where it
breaks: http://codemirror.net/demo/sublime.html

It may have something to do with a focused input.

On Tue, Jan 6, 2015 at 8:44 AM, Stephen Blott notifications@github.com
wrote:

Vimium does not allow propagation of any webpage's Escape keyup bound
events

Really?

Test:

watch = (type) ->
document.addEventListener type, (event) ->
para = document.createElement "p"
para.innerHTML = type
document.body.appendChild para

watch "keydown"
watch "keypress"
watch "keyup"

Running here http://smblott.computing.dcu.ie/escape.html. Looks the
same to me with or without Vimium.

To repeat...

What behaviour would you like to see from Esc?

Perhaps it would be helpful if you could point us to a specific page, so
we all have a specific use case in mind.


Reply to this email directly or view it on GitHub
#499 (comment).

It does have to do with an input being focused.
http://codepen.io/ZombieHippie/pen/zxoXwW

On Tue, Jan 6, 2015 at 8:49 AM, Cole Lawrence msgzht@gmail.com wrote:

I'm looking at your demo right now, this is specifically a case where it
breaks: http://codemirror.net/demo/sublime.html

It may have something to do with a focused input.

On Tue, Jan 6, 2015 at 8:44 AM, Stephen Blott notifications@github.com
wrote:

Vimium does not allow propagation of any webpage's Escape keyup bound
events

Really?

Test:

watch = (type) ->
document.addEventListener type, (event) ->
para = document.createElement "p"
para.innerHTML = type
document.body.appendChild para

watch "keydown"
watch "keypress"
watch "keyup"

Running here http://smblott.computing.dcu.ie/escape.html. Looks the
same to me with or without Vimium.

To repeat...

What behaviour would you like to see from Esc?

Perhaps it would be helpful if you could point us to a specific page, so
we all have a specific use case in mind.


Reply to this email directly or view it on GitHub
#499 (comment).

Collaborator

smblott-github commented Jan 6, 2015

I'm not sure what you want me to do.

I go to which page?
I do what?
What happens?
What do you want to happen?

Sorry for lack of explanation :-)

If you go to my code pen http://codepen.io/ZombieHippie/pen/zxoXwW which I
include your escape.coffe code in, you will see differences between
pressing escape while the input is focused and when it isn't.

In the codepen click on the input to focus, then compare behaviors of
pressing Escape:

No Vimium: The input does not lose focus upon pressing escape.
Vimium: The input does lose focus upon pressing escape.

tested on Chrome 39

On Tue, Jan 6, 2015 at 8:56 AM, Stephen Blott notifications@github.com
wrote:

I'm not sure what you want me to do.

I go to which page?
I do what?
What happens?
What do you want to happen?


Reply to this email directly or view it on GitHub
#499 (comment).

Collaborator

smblott-github commented Jan 6, 2015

Yes, that's right. Because, when an input is focused, Vimium does grab and use Esc. Thats a feature.

Now, what do you want to happen? One possibility would be:

  • If the page handles Esc, Vimium doesn't.
  • Otherwise, it does.

But there are problems with this.

  • Currently, Vimium handles the Esc before the page gets a chance to see it. This is nearly always the right thing to do. If it were otherwise, the Vimium UX would be different on different pages.
  • We could wait to see whether the page uses the event. However, it's not clear whether we could reliably detect that.
Collaborator

smblott-github commented Jan 6, 2015

In fact, taking the case of CodeMirror, we have no way of knowing whether the Esc was handled or not. Their handler returns true regardless of what it did.

I can see where this feature is (very) desirable (if not required for
keyboard dedicated browsing), and I don't think there is an obvious
solution other than adjustable user preferences.

On Tue, Jan 6, 2015 at 9:16 AM, Stephen Blott notifications@github.com
wrote:

In fact, taking the case of CodeMirror, we have no way of knowing whether
the Esc was handled or not. Their handler
https://github.com/codemirror/CodeMirror/blob/master/keymap/vim.js#L667
returns true regardless of what it did.


Reply to this email directly or view it on GitHub
#499 (comment).

Even if you could tell whether CodeMirror handled your Escape event, we
wouldn't have a different way to unfocus CodeMirror via keyboard.

On Tue, Jan 6, 2015 at 9:22 AM, Cole Lawrence msgzht@gmail.com wrote:

I can see where this feature is (very) desirable (if not required for
keyboard dedicated browsing), and I don't think there is an obvious
solution other than adjustable user preferences.

On Tue, Jan 6, 2015 at 9:16 AM, Stephen Blott notifications@github.com
wrote:

In fact, taking the case of CodeMirror, we have no way of knowing whether
the Esc was handled or not. Their handler
https://github.com/codemirror/CodeMirror/blob/master/keymap/vim.js#L667
returns true regardless of what it did.


Reply to this email directly or view it on GitHub
#499 (comment).

Contributor

mrmr1993 commented Jan 6, 2015

Suggest #1372 for this, so <esc> can be a passkey.

Collaborator

smblott-github commented Jan 6, 2015

Suggest #1372 for this, so can be a passkey.

I don't think so. We're in insert mode, so none of the passkey code comes into play.

Contributor

mrmr1993 commented Jan 6, 2015

I don't think so.

I specifically designed it for this use case, it adds a passkey check to exitInsertMode.

00gavin commented Jan 7, 2015

When using the Hangouts extension, Vimium prevents hitting Esc to close a chat window. I would add a "Excluded URLs and keys" rule, but I don't know the "URL" of the chat window. What is the best way to fix this? Thanks.

00gavin commented Jan 7, 2015

I thought this would work, but it does not...

  1. Open chrome://extensions/ and click "Options" under the Hangouts extension
  2. note the URL, something like chrome-extension://sadkjfhaklsjdhfkjhasdfkjh/settingsdialog.html
  3. click the Vimium button
  4. remove settingsdialog.html from the URL in the first box, keeping the *
  5. click the Add Rule button
Contributor

mrmr1993 commented Jan 7, 2015

  1. note the URL, something like chrome-extension://sadkjfhaklsjdhfkjhasdfkjh/settingsdialog.html
  2. click the Vimium button
  3. remove settingsdialog.html from the URL in the first box, keeping the *

Vimium can't run on chrome-extension:// URLs for other extensions, so this will have no effect. If the chat windows do have a chrome-extension:// URL then we're not blocking <esc> (or doing anything else) on them anyway.

  1. don't hit the literal Esc key, but instead type the three letters Esc in the second box

This makes us pass E, s, and c to the page.

Currently we don't support the <esc> key (or any keys that aren't a single character) in the "Excluded URLs and keys" rule. I've created #1372 for this purpose, but it's not available at the moment. If/when it is, entering <esc> (separated by spaces from any other passkeys) should block the <esc> key.

What is the best way to fix this?

If you find out what the chat window URLs are, you could block Vimium completely on them (assuming they're not chrome-extension:// URLs). We don't provide anything else in options that would help at the moment.

00gavin commented Jan 7, 2015

Thanks, Matt. Bummer. So no solution here. Would love to see a built-in ignore for Hangout extension chat windows. Cheers.

I would also like to see a way to pass to the list of ignored keys when wanting to ignore on certain sites. (Or maybe remap it universally to something else...)

zieren commented Mar 6, 2016

+1 for supporting "unmap ". Catching ESC makes working with Google Spreadsheets very annoying: When you entered something in a cell and want to abort, you need to press return and then undo because the normal way, pressing ESC, isn't propagated. Similarly for other apps.

Given that this issue is pretty old, maybe there's a workaround by now that I haven't managed to find?

Collaborator

smblott-github commented Mar 6, 2016

@zieren. The next (full) release will have a passNextKey command. See #1985.
That should catch your use case.
Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment