New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix disabled option not updating when property changes #4818
Conversation
Consider the element's current disabled state instead of the cached one for disabled elements. This fixes the problem where disabled options couldn't be re-enabled.
Altered the line break to the correct format.
I never used this kind of workflow before, my bad on the line break. I tried creating a test for this specific issue but I still know very little of QUnit unfortunately. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This check is in place in most other places, mostly because we have run into widespread issues under similar circumstances and we like to avoid those, but it was forgotten here. There also were no tests covering this, so it was never caught. This adds tests that ensure that the option in the results list will be generated with the correct "disabled" state based on whether or not it, or a parent element, is marked as disabled. This should have been easy: just check `element.disabled` Unfortunately the `disabled` property is not inherited within the option chain, so if an `<optgroup>` is disabled, the `<option>` elements or other `<optgroup>` elements held within it do not have their `disabled` property set to `true`. As a result, we needed to use the `matches` method to check if the `:disabled` state is present for the element. The `matches` method is part of the official standard, but it was not implemented under that name for a while and as a result Internet Explorer only supports it under the prefixed `msMatchesSelector` method and older versions of Webkit have it implemented as `webkitMatchesSelector`. But once we use this method, it appears to consistently return the expected results. This `matches` method and prefixed predecessors are not supported in IE 8, but they are supported in IE 9 and any browsers newer than that. Instead of buulding a very hacky solution using `querySelectorAll` that was brittle, I have chosen to act like everyone else and pretend IE 8 no longer exists. Fixes #3347 Closes #4818
This check is in place in most other places, mostly because we have run into widespread issues under similar circumstances and we like to avoid those, but it was forgotten here. There also were no tests covering this, so it was never caught. This adds tests that ensure that the option in the results list will be generated with the correct "disabled" state based on whether or not it, or a parent element, is marked as disabled. This should have been easy: just check `element.disabled` Unfortunately the `disabled` property is not inherited within the option chain, so if an `<optgroup>` is disabled, the `<option>` elements or other `<optgroup>` elements held within it do not have their `disabled` property set to `true`. As a result, we needed to use the `matches` method to check if the `:disabled` state is present for the element. The `matches` method is part of the official standard, but it was not implemented under that name for a while and as a result Internet Explorer only supports it under the prefixed `msMatchesSelector` method and older versions of Webkit have it implemented as `webkitMatchesSelector`. But once we use this method, it appears to consistently return the expected results. This `matches` method and prefixed predecessors are not supported in IE 8, but they are supported in IE 9 and any browsers newer than that. Instead of buulding a very hacky solution using `querySelectorAll` that was brittle, I have chosen to act like everyone else and pretend IE 8 no longer exists. Fixes #3347 Closes #4818
This fixes the problem where disabled options couldn't be re-enabled.
This pull request includes a
The following changes were made
Fix for #3347