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

[Firefox] Vimium shortcuts don't work after Ctrl-Enter in Gitlab diff viewer #2622

Open
inducer opened this issue Aug 29, 2017 · 9 comments
Open

Comments

@inducer
Copy link

inducer commented Aug 29, 2017

Using vimium 1.59.9, add a comment in the Gitlab diff viewer, e.g. here:

https://gitlab.com/inducer/comment-dumpster/commit/7a90f4b74f70afa6d83bcfc5214c600a6d50b208

To do so, log in and click on the little speech bubble to the left of a line in a diff. (I've created that project to demonstrate this issue, so feel free to litter it up with comments.)

Hit Ctrl-Enter to submit your diff comment. Notice that none of the vimium shortcuts work any more.

@smblott-github
Copy link
Collaborator

I don't want to add a spurious comment to your example page just to check, but perhaps it is similar to here on Github, where an input remains focused after a comment is submitted.

Does <Escape> solve the problem.

@inducer
Copy link
Author

inducer commented Aug 29, 2017

It doesn't, as far as I can tell.

@lydell
Copy link

lydell commented Aug 31, 2017

perhaps it is similar to here on Github, where an input remains focused after a comment is submitted

(As a side note, I actually emailed Github about this keyboard accessibility problem once and got a response that they would take a look at it, but nothing has happened ;) )

@smblott-github
Copy link
Collaborator

BTW... I run my own instance of Gitlab and cannot reproduce this issue there.

@mrmr1993
Copy link
Contributor

If memory serves, I suspect this is another manifestation of the Firefox focus bug: an element which is focused and becomes unfocusable doesn't get blurred. This causes a few problems:

  • If the element can no longer receive key* events (eg. it's display: none), the events aren't fired anywhere in the DOM, and we correspondingly can't catch them.
    • this is a showstopper, and a possible cause of this.
  • The element doesn't ever dispatch its own blur events, and doesn't blur on calls to .blur()
    • this neuters our blurring for insert mode, but mostly doesn't matter because we never get the event (1st bullet).

I can't find the FF issue at the moment, I'll look again later.

@eejdoowad
Copy link

I fixed this bug in Saka Key by checking document.activeElement on every keydown event in text mode. Maybe you could try something similar?

https://github.com/lusakasa/saka-key/blob/master/src/modes/text/client.js#L10

(Returning 'Reset' will cause the document.activeElement to be checked. If it is a text input, stay in text mode. If not, switch to command mode)

@lydell
Copy link

lydell commented Sep 1, 2017

@wshanks
Copy link

wshanks commented Sep 3, 2017

@inducer Have you tried with the focus stealing preference on/off? See also #2613

@inducer
Copy link
Author

inducer commented Sep 4, 2017

I assume you mean "Don't let pages steal the focus on load". If so, no, that makes no difference either way.

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