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

Remove 100ms lag on blur by using custom blur and focus events. #2990

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

adunkman
Copy link
Contributor

@harvesthq/chosen-developers /cc @jisraelsen

This PR changes the way focus tracking occurs, relying on focusin and focusout events on the Chosen container instead of focus and blur events on the search input itself. The key benefit is that when the search input is blurred in the process of clicking on a search result item, focus is still maintained within the Chosen container. This allows us to drop our mouse_on_container tracking as well as the 100ms-delayed blur_test.

For a quick review of the events used here:

focus focusin blur focusout
When? When an element is focused. When an element is focused. When an element is blurred. When an element is blurred.
Where? Triggered on the element which is focused and does not bubble up the DOM. Triggered on the element which is focused and every element which contains it (it bubbles up the DOM). Triggered on the element which is focused and does not bubble up the DOM. Triggered on the element which is focused and every element which contains it (it bubbles up the DOM).

I’ll drop a few inline notes to explain more!

This allows us to accurately catch mouse events on elements within the container, removing the need to do manual focus tracking in our code.
We can instead rely on our custom focus and blur events now.
@@ -8,6 +8,9 @@ $chosen-sprite-retina: url('[email protected]') !default;
vertical-align: middle;
font-size: 13px;
user-select: none;
&:focus {
outline: none;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adunkman Just to double check: this just removes some extra extraneous focus on some unexpected element, right? Chosen currently styles properly on focus like you'd expect (good for accessibility!), so I'm hoping this is just that!

Copy link
Contributor Author

@adunkman adunkman May 31, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct! This removes a focus rectangle around the Chosen DIV itself, which only occurs when clicking on search results (after the search input has blurred but before the search result is selected). It’s a side effect of adding tabIndex — it’s quite jarring, since it’s an unexpected element to receive focus in this case.

@@ -34,6 +34,7 @@ class Chosen extends AbstractChosen
container_props =
'class': container_classes.join ' '
'title': @form_field.title
'tabIndex': '-1'
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When attempting to click on an item in the Chosen drop but missing by a pixel or two, we don’t want the Chosen drop to close. We can add a tab index, which allows it to receive focus — resulting in the following:

  1. The search input has focus, and the user attempts to use their mouse to click on a result.
  2. The user begins clicking. The search input blurs, triggering a focusout event, which is caught on the container and a setTimeout is scheduled.
  3. The container receives the mouse event, which focuses the container. The container triggers a focusin event, which is caught on the container and nothing happens (@active_field is true).
  4. The setTimeout expires, checking to see if the container contains document.activeElement, which is in this case, itself. As defined in the spec, a Node .contains() itself, and therefore the drop is not closed.

@container.on 'focusin.chosen', (evt) => this.container_focusin(evt); return
@container.on 'focusout.chosen', (evt) => this.container_focusout(evt); return
@container.on 'chosen:blur.chosen', (evt) => this.close_field(evt); return
@container.on 'chosen:focus.chosen', (evt) => this.input_focus(evt); return
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think relying on custom events here (chosen:blur and chosen:focus) are the most straightforward way to handle this — but we can also just simply inline the calls to input_focus and close_field in the container_focusin and container_focusout events below. Let me know which you prefer!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This suggests that those events can/should be invoked from a client implementation, which I think is not the case, right? So I think inlining them below would be better.

if not @mouse_on_container
@active_field = false
setTimeout (=> this.blur_test()), 100

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we now only trigger our chosen:focus and chosen:blur events when focus is lost on the entire container or its descendants, we no longer need to track mouse positioning.

@koenpunt
Copy link
Collaborator

koenpunt commented Jun 2, 2018

Looks promising, but does is work cross browser?

@koenpunt
Copy link
Collaborator

koenpunt commented Jun 3, 2018

Also, how does it behave when having focus in the input and then pressing tab? Especially in the case when the cursor is still positioned over the Chosen select. Because I can imagine that the focusout event might not be triggered then.

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

Successfully merging this pull request may close these issues.

3 participants