This repository was archived by the owner on Dec 15, 2022. It is now read-only.
Tab bar shouldn't be focusable #440
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
matthewwithanm
changed the title
This was originally added way back in 310c058 however, a tabindex of -1 means that the tab bar can receive focus. As a result, focus would end up being transferred to the tab bar as part of the default action of the mousedown handler. When the `Pane` is activated, it would see that its child (the tab bar) had focus and leave it there, meaning the tab bar (instead of the editor) would retain focus. This behavior was first reported in #14173, however the original fix for it (#14175) resulted in Panes always stealing the focus from their children. This regression was rectified with atom/atom#14403 and #439, but really the tab bar shouldn't be focusable in the first place. Making this adjustment means we no longer have to delay the activation of the item and pane (#150 and atom/tabs#tabs#439) since the focus will no longer be given to the tab bar as part of the default action of the mousedown handler.
matthewwithanm
force-pushed
the
fb-mdt-dont-make-tabbar-focusable
branch
from
28ef8e1 to
37c8868
Compare
1 task
|
Resolve conflicts and ensure the builds are green then this can be merged! 👍 |
|
Ping. If you can update this so it merges, we'll merge it. |
maxbrunsfeld
approved these changes
Nov 28, 2017
|
hey! it looks like almost all of this work was done done by the PR that switched the interaction from mousedown to click, except removing the tabindex attribute. there's probably no harm in removing the tabindex but, given the other change, there isn't really a motivator for doing it either so i'm going to close. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This was originally added way back in 310c058 however, a tabindex of -1
means that the tab bar can receive focus.
As a result, focus would end up being transferred to the tab bar as
part of the default action of the mousedown handler. When the
Paneisactivated, it would see that its child (the tab bar) had focus and
leave it there, meaning the tab bar (instead of the editor) would
retain focus. This behavior was first reported in #14173, however the
original fix for it (#14175) resulted in Panes always stealing the
focus from their children. This regression was rectified with
atom/atom#14403 and #439, but really the tab bar shouldn't be
focusable in the first place. Making this adjustment means we no longer
have to delay the activation of the item and pane (#150 and
atom/tabs#tabs#439) since the focus will no longer be given to the tab
bar as part of the default action of the mousedown handler.
This shouldn't be merged until after 1.17 leaves beta. For the 1.17 beta, atom/atom#14403 and #439 are the less invasive fixes.
cc @ungb