For a ComboBox that is configured with "allowFreeForm" being true, if the user clicks on the scroll bar of the dropdown menu in order to scroll to an option to select, it invokes onBlur handler unexpectedly (technically the user's focus is still on the ComboBox as a whole). In comparison, Fabric Dropdown component doesn't have this issue.
Are you willing to submit a PR to fix? No
Requested priority: High
Products/sites affected: SPO
Add a ComboBox that is configured with "allowFreeForm" to be true and large number of options so that a scroll bar is shown in the dropdown menu. The user clicks on the arrow to open the dropdown menu. Then the user clicks on the scroll bar in the dropdown and try to drag it down or up.
Actual: onBlur handler is invoked unexpectedly.
Expected: onBlur handler is not invoked because technically the interaction is still on the ComboBox. (Drowdown control doesn't invoke onBlur in this situation)
Have you checked to see if this is still the behavior in our current release? If so, we can try to work out a fix and backport it to 5.x.
@micahgodbolt, Sorry, it was my mistake previously. We are actually using version 6.61.2. I updated the bug report above too. Thanks!
I'm able to repro this in isolation, here's a Codepen: https://codepen.io/kevintcoughlin/pen/gdJdZj?editors=1010
And here's a Codepen with a similar <Dropdown/> not exhibiting the same onBlur behavior: https://codepen.io/kevintcoughlin/pen/vzwVyz?editors=1010
Tagging as a bug given the above repros.
@KevinTCoughlin @stanleyymsft Found a fix for when clicking on Scrollbar not to call the onBlur handler but I noticed that it's called also when clicking the arrow to open the ComboBox. Is this something needs to be fixed too, cause it follows the same logic (technically the user's focus is still on the ComboBox as a whole) as the author of the issue states.
:tada:This issue was addressed in #6475, which has now been successfully released as [email protected].:tada:
Handy Links:
Thank you!
Reopening as there is still some weird onBlur invocation happening. See details in the discussion with the original author in #6475
@Vitalius1 Are you still working on this one?
@mikewheaton not as of now. Do you think Shield could pick this one up?
Ok, I've looked at this for a bit and I think I know what's going on. The _onBlur handler is bound to the Autofill component, which means it can only trap blur events from that subtree. This subtree does not include the Callout component nor any of its elements. That means that onBlur events from the Callout can't be blocked or filtered as ComboBox is currently written.
Additionally, whenever a user simply hovers over a callout element, focus is set on Autofill, which is outside of the hierarchy of the Callout. As a result, an unblockable onBlur event is triggered just by hovering on a Callout element after clicking on the scroll bar. This is what's causing the onBlur event that @stanleyymsft described in #6475. (Unblockable as the blur event comes up the Callout hierarchy, bypassing the _onBlur handler bound to Autofill.)
Unfortunately I'm not sure the best way to approach fixing this. I have some questions like:
Autofill focused just by hovering over elements?_onBlur be at a higher level where it can block blur events from the Callout or is another higher level blur handler required?I'm hoping @jspurlin can give his thoughts...
Not sure why an onBlur is firing on hover, the autofill should already be focused... In general the autofill needs to continue to have focus when hovering over elements so that the user can continue to type in the input. When the user hovers we keep track of which item is hovered so that the user (if they just hover over an items) can press ENTER and it will select the hovered item.
Having onBlur at at full comboBox level where it can handle all the onBlur events sounds good. It looks like the current _onBlur is attempting to do that by checking if a blur is coming from within the the root or within the combBoxMenu...
Just to clarify, when you click on the scroll bar to scroll items in the Callout, it grabs focus from the Autofill. Then a hover event over a callout item causes focus to go back to Autofill, which fires an onBlur event (originating from Callout) and bubbling up to the component consumer.
The current _onBlur can only trap events when Autofill loses focus (if the focus moved TO Callout) but not when onBlur events come FROM Callout.
Thanks for the input!
Ah, I missed the scrollbar aspect of this issue. Yeah, focus should always stay in the input (Autofill) of the ComboBox while the user is interacting with the ComboBox
I don't think there's a way to keep focus on Autofill currently when the users clicks on the Callout scrollbar. The way ComboBox is architected now I think Callout would somehow have to be a child of Autofill to make that possible, but I don't think Autofill can take children that way... did you have an idea in mind for that?
Nope, but in my mind I think that the ComboBox should be the own driving focus retlated things all up for itself
this might be something to look into during the work in #6030 @ecraig12345
@stanleyymsft is this important to resolve? what is the effect of this on SharePoint?
Dropdown works because 'onBlur' is faked. We control 'focus' of the Dropdown with state, and we only fire onBlur if the dropdown was already closed by the event.
Combobox onBlur is normal input focus, and clicking outside of the Combobox causes the input to lose focus.
i.e. i'm not sure if there is a way to keep onBlur from firing when the input in fact loses focus. We can always return focus to the input, but not without an onBlur already being called.
:tada:This issue was addressed in #11584, which has now been successfully released as [email protected].:tada:
Handy links:
Most helpful comment
:tada:This issue was addressed in #6475, which has now been successfully released as
[email protected].:tada:Handy Links: