Commits on Jul 10, 2019

1. Results respect disabled state of <option> …

   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

   

   kevin-brown committed Jul 10, 2019
   Copy the full SHA

   6d0fa49 View commit details

   Browse the repository at this point in the history