relatedTarget in blur event in Firefox returns null always

[leoasis]

Basically that, the relatedTarget is returning null all the time, when in Chrome it is returning the correct value if clicking on an actual element (will return null if clicking outside the document, which is ok).

This is something that Firefox is doing natively, so there should be some "patch" in that case to make it cross browser as a syntethic event.

Here is an example: http://jsfiddle.net/leoasis/kb3gN/4476/ Click the first input and then the second, and you'll see in the console: a) the relatedTarget if in Chrome, or b) null if in Firefox.

[zpao]

cc @syranide our resident event export these days

[syranide]

Haha, I believe I've seen some code in there that's meant to fix this, I'll have a look tomorrow and see what's going on. @leoasis I'm curious what you need this for.

[leoasis]

Basically I'm trying to show some contextual elements whenever I'm focused in a component. So I have an onBlur handler at the root of my component and use the relatedTarget (which in a blur event is the element where i'm going TO) and check wether that element is inside the root one or not to figure out if I'm actually leaving the component or not.

I worked it around right now by checking the same but with clicks, attaching the handler in the document object and doing the same check. It works, but only for clicks (pressing tab won't work for example).

[syranide]

@leoasis That sounds like something you could/should solve with onMouseEnter and onMouseLeave. There's generally no reason to use the reported nodes in an event for React. That being said it should still be fixed.

[leoasis]

Actually I want to show/hide things when focused, not when I'm hovering. Think about a contextual dropdown menu for example.

[syranide]

@leoasis So onFocus and onBlur then? Or whichever event fits your use-case. It's your choice obviously, but I'm quite certain that your solution has a React-only solution.

[leoasis]

That's actually what I used, the thing is that onBlur is bubbled to the root element in the component whenever anything inside is blurred. So I still want to check if the relatedTarget (the next element being focused) is still inside the component.

[syranide]

@leoasis event.stopPropagation() I think?

[leoasis]

@syranide I think that won't work in this case, since I don't want to handle the blur events in the children, I am handling the event in the top element inside the component, so I want to have the events propagated to that one.

[syranide]

Yep, your choice, but AFAIK, the React-way would be to handle it in the children and propagate a callback through props instead. Anyway, I'm going to have a look at fixing this either way.

[leoasis]

Thanks for taking a look at it!

Anyway, I think I'm still not clear in what I need to do, and I don't think the React way is to traverse the entire children adding blur and focus handles to just see if i'm blurring out of the component or not. To be clear, this is a simplified version of what I'm trying to do, in a fiddle:

http://jsfiddle.net/leoasis/VkebS/569/

Notice that I want to be able to select the , and also I want it to disappear when I click or tab outside, for example in the other input or anywhere else

[syranide]

@zpao @leoasis OK, so event.nativeEvent.relatedTarget is apparently always null in FireFox (and IE11) for FocusEvents. The FocusEvent does not provide any information on the element being focused. So there doesn't seem to any easy fix for this that isn't relatedTarget = null.

I imagine it could be solved by simply keeping track of the last focused element, but I suspect that it's more fragile in practice than you would expect, so it would probably not be a great fix. It also doesn't really fit with how React is meant to be used...

So that's another interesting topic, how should/would you accomplish this with React? There's inherently nothing we can put in events that would make sense, I think. You could probably track focused element in the parent and if the parent discovers it doesn't have a focused element during componentWillUpdate (can't call setState there...) it would be the signal to close, batching should prevent the time between blur to focus from being a problem I think.

[syranide]

Follow-up to the previous, I haven't tested it yet, but I imagine onFocusIn and onFocusOut is the correct solution to all problems? (both React and non-React)

[leoasis]

If I'm not wrong, focusin and focusout events are not supported in Firefox yet: https://developer.mozilla.org/en-US/docs/Web/Events/focusin

[syranide]

Hmm, it says listening to focus with capture should have a similar effect (onFocusCapture in React I think?), perhaps there's something there we can use to shim it... although the persistent threat of event.stopPropagation being called outside React's control is always there.