Skip to content
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

Switch order of matching conditions in Element Send Keys #1434

Open
julianrkung opened this issue Jul 16, 2019 · 0 comments
Open

Switch order of matching conditions in Element Send Keys #1434

julianrkung opened this issue Jul 16, 2019 · 0 comments

Comments

@julianrkung
Copy link

In chapter 12. Elements, section 12.4 Interaction:

Below is an excerpt of step 8 of Element Send Keys where we must pick the "first matching" case. If, for example, the user attempts to send keys to a contenteditable p element, if the spec is followed precisely it will never reach the "Element is content editable" case as the above case always qualifies as "something other than a text input control"

The user agent renders element as something other than a text input control (for example an input element in the color state being presented as a colorwheel):

  1. If element does not have an own property named value return an error with error code element not interactable
  1. If element is not mutable return an error with error code element not interactable.
  1. Set a property value to text on element.
  1. If element is suffering from bad input return an error with error code invalid argument.
  1. Return success with data null.

Element is content editable

  1. Set the text insertion caret after any child content.

I believe the problem would be fixed if the two cases below have their order switched.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant