Results respect disabled state of <option>#5560
Merged
Merged
Conversation
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 was referenced Apr 8, 2020
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.disabledUnfortunately the
disabledproperty is not inherited within theoption chain, so if an
<optgroup>is disabled, the<option>elements or other
<optgroup>elements held within it do not havetheir
disabledproperty set totrue. As a result, we needed touse the
matchesmethod to check if the:disabledstate ispresent for the element. The
matchesmethod is part of the officialstandard, but it was not implemented under that name for a while and
as a result Internet Explorer only supports it under the prefixed
msMatchesSelectormethod and older versions of Webkit have itimplemented as
webkitMatchesSelector. But once we use this method,it appears to consistently return the expected results.
This
matchesmethod and prefixed predecessors are not supported inIE 8, but they are supported in IE 9 and any browsers newer than
that. Instead of buulding a very hacky solution using
querySelectorAllthat was brittle, I have chosen to act likeeveryone else and pretend IE 8 no longer exists.
Fixes #3347
Closes #4818
This pull request includes a
The following changes were made
disabledproperty on optionsdisabledbehaviour on options in<select>elements