React-Select component with properties crash Firefox on Windows 10

[devonbalicki]

Affects Firefox 51.0.1 on Windows 10 32 and 64 bit

When loading a React-Select component that has properties set causes the browser window to crash.

let props = this.props;
        return (
                <ReactSelect {...props} noResultsText={ '' }/>
        );

This loads fine:

let props = this.props;
        return (
                <ReactSelect/>
        );

Crash report: https://crash-stats.mozilla.com/report/index/20c12273-27b2-4e1c-b49f-874492170131

cc @peixian @tab1293

[amolbarewar]

the same issue is happening for our team also. We are facing problem on Firefox version 51.0.1 in Windows Operating system only.
We are using below code snippet.
<Select className = "block" clearable = {false} name = "hours" onChange = {e => onStateChange(e.value, 'scheduletime', 0)} options = {hoursSelect} searchable = {false} value = {(scheduleTime || '00:00').split(':')[0]} />

[domehead100]

I have a user who reported a hang on Firefox 51.0.1 today on a page using react-select 1.0.0-rc.3. She's on Windows 8.1. That crash report posted earlier seems to indicate that the hang was caused by Shockwave Flash, I'll check with my user tomorrow. Will try disabling hardware graphics acceleration, removing Shockwave if it's installed.

The same page works fine for me and some other users on the same version of Firefox.

Must be either a FF bug or due to some extension that the user has installed, right? My page works fine in Chrome and IE 11 (not as pleasant of an experience in IE 11, but it works).

[blackChef]

Same issue here. Browser freezing seems to be random on our product.

[peixian]

@domehead100 It doesn't seem to be an extension, since FF 51.0.1 still crashes in safe mode with it, so I'm inclined to say it's a weird Windows specific FF bug.

[domehead100]

Yeah, probably right; I wasn't sure if safe mode disabled all extensions, plugins, etc.

My user today reports that FF updated this morning when she started it, and now everything works without issues. She's on Windows 8.1.

[critesjm]

Same occurs on a completely fresh install of FFox 51.0.1 x32/x64 on Win7.

[critesjm]

Further diagnosis: happens when the user has Firefox accessibility settings enabled. going into about:config and setting accessibility.force_disable to 1 eliminates the problem.

[omgaz]

I'm not seeing the problem on FF 51.0.1 x32/x64 on Win10. My accessibility.force_disable is also set to 0. Running the rc2. Anyone else having this problem on react-select rc2 and above?

[ghost]

We debugged the problem with the component. It was happening when we were using searchable property as false with React-Select component. Quite weird, but we added a hack around it and resolved the issue.

[noveyak]

We are experiencing this too on FF 51.01 and Win 10 (But not mac). It seems like 1.0.0-beta13 and earlier still seem to work because all the aria props were not introduced in the code yet. The component also seems to render ok if it is !disabled && searchable && autosize because it goes into a separate render branch.

[critesjm]

@omgaz if you set that to -1 it'll force the settings on and may help you to see it.

[ykabisher]

Also happens on windows 7 64Bit / FF51
http://jedwatson.github.io/react-select/
in the first example, when disabled is checked or search is unchecked, FF crashes

[mhubenthal]

It appears that Firefox is getting stuck in some kind of infinite loop due to incorrect use of aria-owns attribute. Here's the W3C spec on aria-owns:

https://www.w3.org/TR/wai-aria/states_and_properties#aria-owns

In Select.js, line 879, when isOpen is false, the component assigns this._instancePrefix + '-value' to aria-owns. That value corresponds to a DOM node which is a parent, and thus has a hierarchical relationship, breaking the W3C spec.

If you visit the demo in Chrome (https://jedwatson.github.io/react-select/) and inspect the HTML, you'll see that in the situation when the component would be breaking Firefox, Chrome has intelligently removed the offending aria-owns value.

cc: @critesjm @pagevest

[mhubenthal]

PR with a fix is out: #1556

[agirton]

#1556 was merged. Closing.