Dispatched blur event causes false test failures for components using event.relatedTarget checks

[drewlee]

This regression was introduced in v2.0.0 as a result of PR #918.

It's fairly common for UI overlay-type widgets (e.g., dropdowns, tooltips, typeaheads, etc.), to utilize checking of the event.relatedTarget property to control the visibility and state of the associated overlay elements. For example, within the context of a focusout event handler, the relatedTarget property references the element which just gained focus. This is useful to determine whether the newly focused element is a descendent of a component, as demonstrated at https://github.com/drewlee/eth-rtarget/blob/5a083c65b323e9261ff69b04d217f1d3915cf993/app/components/basic-dd.js#L16. A non-descendant element signifies that the associated overlay can be dismissed. This is very practical for handling interactions where a user Tabs out of a dropdown menu, or clicks outside of a particular widget.

However, since introducing blur to fire before each invocation of focus, this behavior is no longer working properly in tests, causing overlays to prematurely dismiss. Since the event.relatedTarget property from the simulated event has a null value, the component assumes that focus has moved out of the browser window and dismisses.

A reproduction of this case has been created at https://github.com/drewlee/eth-rtarget with an associated test case at https://github.com/drewlee/eth-rtarget/blob/5a083c65b323e9261ff69b04d217f1d3915cf993/tests/integration/components/basic-dd-test.js#L9. For comparison purposes, there's a branch using an older version of @ember/test-helpers, where the test passes as expected: https://github.com/drewlee/eth-rtarget/tree/old-deps.

[rwjblue]

In order to fix this, we will have to significantly change the strategy from #918. Instead of calling the existing __blur__ shared function, we will need to fire the appropriate events manually (via the fireEvent mechanism) so that we can set the proper options.

[ro0gr]

@rwjblue that was my first fear as well. However, it looks like we could just pass the relatedTarget to the FireEvent. Haven't tried it yet though.

Btw, great report!

[ro0gr]

we could just pass the relatedTarget to the FireEvent

hm.. this code branch is supposed to work for browserIsNotFocused only case, so it doesn't seem to be a solution..

[drewlee]

Fixed with PR #965