No blur event fired when button is disabled/removed

[OliverJAsh]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
When a focussed button becomes disabled, React does not dispatch a blur event.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar (template: https://jsfiddle.net/reactjs/69z2wepo/).

1. Attach a blur event to a button
2. Focus the button
3. Make the button disabled or remove it from the DOM

What is the expected behavior?
A blur event will be dispatched.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
15.1.0, not sure if it worked in previous versions.

Isolated test case: http://jsbin.com/fuvite/1/edit?html,css,js,output

[OliverJAsh]

Hmm, I don't want to mutate the DOM. Disabled is a field in my state that I want to use when rendering

[jddxf]

Just use setState.See http://codepen.io/inamessnow/pen/XMMYLK?editors=0010

[aweary]

Calling ReactDOM.render again should act identically to renders triggered from setState. React does not re-create the element in this case (watch it in devtools)

@OliverJAsh I tried your demo and I see both blur and blurCapture events working just fine:

Using Chrome 56. Is there a specific browser you were having this issue with? Also, it sounds like you are using setState to trigger the render in your actual application, but if you are using ReactDOM.render to re-render an application we do recommend avoiding that in most cases.

[OliverJAsh]

@aweary Please see the gif demo below. In the demo, you can see my vanilla event listener is logged, but the React blur and blurCapture event listeners are not (when the button becomes disabled). The updated code is at http://jsbin.com/loqoquzuye/1/edit?js,output

[aweary]

@OliverJAsh can you verify what browser you're using? I can't reproduce in Chrome 56, but I can reproduce it in Chrome 57. It looks to be browser-specific.

Button focus behavior is not well defined and inconsistent between browsers. For example, using this example with plain JavaScript neither Firefox nor Safari on OSX fire focus or blur events for buttons. I'm not sure if we normalize this behavior at all yet, but we probably should.

It's also worth noting that you are listening for the blur event on a div, which is not an element that can receive focus by default (Chrome seems to ignore that). You'll notice that you're example doesn't work in Firefox or Safari (OSX) even if you don't set disabled. To resolve that you'd need to set tabIndex on the div which lets it receive focus.

[OliverJAsh]

can you verify what browser you're using?

I'm using Chrome 59 (dev channel).

Button focus behavior is not well defined and inconsistent between browsers. For example, using this example with plain JavaScript neither Firefox nor Safari on OSX fire focus or blur events for buttons. I'm not sure if we normalize this behavior at all yet, but we probably should.

Interesting, I didn't realise this.

It's also worth noting that you are listening for the blur event on a div, which is not an element that can receive focus by default (Chrome seems to ignore that)

The blur event does not bubble up to the div, but can be listened to using event capturing (on the way down as opposed to on the way up). This is why I would expect React—when using Chrome—to follow the behaviour of Chrome's event model.

[aweary]

@OliverJAsh It's a tough problem, the reason Chrome's blur event is being ignored is because we explicitly ignore events while reconciliation is occuring. React has an internal transaction system to make sure that updates are atomic, and when a new transaction is initialized it calls ReactBrowserEventEmitter.setEnabled(false) so we don't get a bunch of events that might be dispatched as React is messing with the DOM.

Since Chrome's blur event is dispatched right after React updates the disabled attribute and before the transaction is closed out it gets ignored. To support this we would have to special case this scenario, and I'm not quite sure yet if there's a way to do that well.

[sebmarkbage]

It seems to me that this is a job for ReactInputSelection. In it, we track the currently focused element before reconciliation and then we restore it after reconciliation. We are unable to restore the focus and it is silently ignore.

If the focusNode operation fails, we should dispatch the blur event ourselves since we know that a blur must have happened as a result of reconciliation in this case.

[sebmarkbage]

I think it is fine to special case this because this is already a special case for focus management and we don't have any other plan for it atm. Other than possibly introducing "pivot points" in the reconciler that avoids touching active trees so that we don't need to do manual focus/selection management. However, even that requires us to special case focus as a pivot point. So it seems pretty inherent that we need something like this special case regardless.

[aweary]

It seems to me that this is a job for ReactInputSelection. In it, we track the currently focused element before reconciliation and then we restore it after reconciliation. We are unable to restore the focus and it is silently ignore.

@sebmarkbage I'm happy to work on adapting ReactInputSelection to something that also supports button focus.

If the focusNode operation fails, we should dispatch the blur event ourselves since we know that a blur must have happened as a result of reconciliation in this case.

The blur event is not consistently dispatched by browsers, so we would have to create a native event in those cases. AFAIK React doesn't do that at the moment (all synthetic events are created with a trusted native event) so is that acceptable? Unless I'm missing where that's already happening