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

Update submission on {enter} to only occur if more than 1 input element that blocks implicit submission when no submit buttons #4574

Merged
merged 5 commits into from
Jul 9, 2019

Conversation

jennifer-shehane
Copy link
Member

…nt that blocks implicit submission when no submit buttons

- Add method to check for inputs of type that block implicit submission
- Add test to ensure form is submitted when only 1 field blocking
implicit submission.
@jennifer-shehane jennifer-shehane requested a review from a team June 26, 2019 12:21
packages/driver/src/dom/elements.js Outdated Show resolved Hide resolved
packages/driver/src/cy/commands/actions/type.coffee Outdated Show resolved Hide resolved
packages/driver/src/cy/commands/actions/type.coffee Outdated Show resolved Hide resolved
@brian-mann
Copy link
Member

The way the spec is written reads awkward - it provides the rule and then backs into "the exception" by redefining all the previous inputs as if they are "the rule".

I'm suggesting that the naming be re-written in the positive / active form - which is "the rule", and the exception being handled later on which overrides "the rule".

These input elements do not BLOCK implicit submission - they actually CREATE implicit submission - and only if there are MORE than 1 of them would that become "the exception" where it DOES NOT implicitly submit the form.

The previous language + logic was correct except we needed to filter down / reduce the list of inputs that cause implicit submission. This PR is written in a way where it seems it's doing a whole lot more because of the reversal of the language, making it difficult to understand why or what is actually happening.

@jennifer-shehane
Copy link
Member Author

So I also thought that the listing of input types was strange to omit datetime altogether. Maybe it's an oversight - will need to manually check how Chrome/Firefox deal with datetime inputs and implicit submission.

@jennifer-shehane
Copy link
Member Author

Actually, it appears that inputs of type datetime are no longer supported. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime

Not exactly sure how to handle this, since we specifically mention supporting datetime inputs in .type() docs. https://on.cypress.io/type#Supported-Elements

@jennifer-shehane jennifer-shehane requested a review from a team July 3, 2019 06:24
@kuceb
Copy link
Contributor

kuceb commented Jul 8, 2019

@jennifer-shehane it was deprecated in favor of datetime-local, which we handle already, so we should probably just find-replace datetime with datetime-local in the documentation/messaging

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

Successfully merging this pull request may close these issues.

type('{enter}') doesn't work when only 1 input blocking implicit submission
3 participants