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.

Sign up for GitHub

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

Jump to bottom

Focus should not reach <body> #2327

Closed
alexdima opened this issue Jan 26, 2016 · 11 comments
Closed

Focus should not reach <body> #2327

alexdima opened this issue Jan 26, 2016 · 11 comments
Assignees
@bpasero
Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues bug Issue identified by VS Code Team member as probable bug electron Issues and items related to Electron help wanted Issues identified as good community contribution opportunities upstream Issue identified as 'upstream' component related (exists outside of VS Code) verified Verification succeeded
Milestone
December/January ...

Comments

@alexdima
Copy link
Member

Testing #2145

setInterval(function() { console.log(document.activeElement); }, 2000);

  • put last editor in Tab moves focus mode via Ctrl+M
  • tab in last editor:

image
@alexdima alexdima added bug Issue identified by VS Code Team member as probable bug accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues labels Jan 26, 2016
@bpasero
Copy link
Member

bpasero commented Jan 26, 2016

@alexandrudima yeah, I am not sure I can disable this actually. maybe I can redirect the focus to the first control somewhere.

@bpasero bpasero mentioned this issue Jan 26, 2016
Closed
@bpasero bpasero modified the milestones: Jan 2016, Feb 2016 Jan 26, 2016
@bpasero
Copy link
Member

bpasero commented Jan 27, 2016

@alexandrudima tried a while now to see if I can prevent keyboard to navigate into the body element and failed to find anything useful. The only super hack I can come up with is to listen globally to Tab-KeyUp and find out if the active element is the body and then move focus to some element within.

If anyone has ideas, they are most welcome.

@bpasero bpasero added the help wanted Issues identified as good community contribution opportunities label Jan 27, 2016
@alexdima
Copy link
Member Author

@bpasero 'focus' listener on <body> ?

@alexdima
Copy link
Member Author

or there was another one 'focusin' - I forgot the exact difference. You can check if the e.target === body

@bpasero
Copy link
Member

bpasero commented Jan 27, 2016

@alexandrudima best I can come up with is this:

window.document.body.addEventListener('blur', function(e) {
   setTimeout(function() { console.log(document.activeElement);});
}, true);

I do not get any focus event on the body element, so listen on blur in the capture phase and use timeout because without, activeElement is === body. Still a bit ugly.

@bpasero bpasero modified the milestones: Backlog, Feb 2016 Feb 2, 2016
@bpasero
Copy link
Member

bpasero commented Feb 2, 2016

I am not really able to do this nicely, moving to backlog.

@alexdima alexdima mentioned this issue Feb 25, 2016
Closed
@bpasero bpasero added the upstream Issue identified as 'upstream' component related (exists outside of VS Code) label Mar 21, 2016
@bpasero
Copy link
Member

bpasero commented Apr 8, 2016

Maybe this will help in Chrome 50: https://developers.google.com/web/updates/2016/03/focus-start-point

@bpasero bpasero added electron Issues and items related to Electron and removed electron-update labels Mar 8, 2017
@bpasero bpasero added workbench and removed bug Issue identified by VS Code Team member as probable bug labels Apr 7, 2017
@cleidigh
Copy link
Contributor

@bpasero
This looks like it also relates to what I'm trying to do with some list navigation improvement with
PR #24628 in dealing with tabindex issues
you still have help-wanted tag shall I take a look at it or is somebody on this?

@bpasero
Copy link
Member

bpasero commented Apr 17, 2017

@cleidigh the issue is that when you tab long enough through the UI you end up in the body element at some point without any visual indication. If possible I wanted to disallow jumping to this element because it does not really help for navigation.

@bpasero bpasero mentioned this issue Jul 19, 2017
Closed
@bpasero bpasero removed the workbench label Nov 12, 2017
@bpasero
Copy link
Member

bpasero commented Nov 14, 2017

Closing as I am seeing no way of doing this currently, if someone wants to fix this, PR me.

@bpasero bpasero closed this as completed Nov 14, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Dec 29, 2017
@bpasero bpasero added the bug Issue identified by VS Code Team member as probable bug label Jan 25, 2019
@bpasero
Copy link
Member

bpasero commented Jan 25, 2019

This is now actually fixed with Electron 3 👍

@alexdima alexdima added the verified Verification succeeded label Feb 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@bpasero bpasero

Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues bug Issue identified by VS Code Team member as probable bug electron Issues and items related to Electron help wanted Issues identified as good community contribution opportunities upstream Issue identified as 'upstream' component related (exists outside of VS Code) verified Verification succeeded
Projects
None yet
Milestone
December/January 2019
Development

No branches or pull requests
3 participants
@bpasero @alexdima @cleidigh