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

type="submit" in fast-button won't work #3534

Closed
PhilippSonntagORGADATA opened this issue Jul 21, 2020 · 4 comments · Fixed by #3603
Closed

type="submit" in fast-button won't work #3534

PhilippSonntagORGADATA opened this issue Jul 21, 2020 · 4 comments · Fixed by #3603
Assignees
Labels
area:fast-foundation Pertains to fast-foundation bug A bug closed:done Work is finished community:request Issues specifically reported by a member of the community.

Comments

@PhilippSonntagORGADATA
Copy link

Hello there,
I want to create a button that submits a form, but the type submit seems not to work on buttons.

The packages I used were fast-components and fast-components-msft of which both don't work. I tried to locate an error in the Button component, but everything seems fine. So this might be unwanted behaviour/a bug.

HTML form to reproduce the missing feature/bug

<script type="module" src="https://unpkg.com/@microsoft/fast-components"></script>
<fast-design-system-provider use-defaults>
  <form action="/action_page.php">
    <label for="fname">First name:</label><br>
    <input type="text" id="fname" name="fname" value="John"><br>
    <label for="lname">Last name:</label><br>
    <input type="text" id="lname" name="lname" value="Doe"><br><br>
<!--     <input type="submit" value="Submit"> -->
    <fast-button type="submit" value="Save">Save</fast-button>
  </form>
</fast-design-system-provider>
  • Tried with the newest version of Edge Chromium and Chrome

Thanks for your help and keep up the good work 👍

-Philipp

@EisenbergEffect EisenbergEffect added area:fast-components area:fast-foundation Pertains to fast-foundation bug A bug status:needs-investigation Needs additional investigation and removed triage labels Jul 21, 2020
@EisenbergEffect
Copy link
Contributor

Thank you for reporting this @PhilippSonntagORGADATA

I can confirm that I have also been able to reproduce this bug with a recent build. We'll investigate this and see if we can determine what is going wrong here and plan out a fix.

@PhilippSonntagORGADATA
Copy link
Author

If you need a workaround for this bug, you could use the solution someone wrote at mwc.

Sadly, this doesn't seem to work quite good in Blazor because the page will be reloaded anyway.

@EisenbergEffect EisenbergEffect added the community:request Issues specifically reported by a member of the community. label Jul 24, 2020
@nicholasrice
Copy link
Contributor

Did a bit of digging on this. There are a number of open issues discussing form-associated-custom-element (FACE) submit buttons:

The issues above discuss various approaches supporting FACE components with form submission capabilities and it seems likely the platform will provide this in the future, but right now it is not supported. There are a few approaches I can think of that we can take in the short term:

1.) FASTButtonInstance.form.submit()

A submit button can determine when form submission should take place and manually invoke the submit method. There are several behavioral differences between submit() and clicking a submit button outlined - see https://developer.mozilla.org/en-US/docs/Web/API/HTMLFormElement/submit for more info:

  • no "submit" event emission
  • no constraint validation

2.) FASTButtonInstance.form.requestSubmit(this.proxy)

This approach circumvents the above two issues and is behaviorally consistent with a user clicking the submitter. It does, however, require that the submitter is a submit button and this API does not currently support being invoked with a form-associated custom elements submit button.

We could take an approach where we briefly append the FASTButton's proxy element which is a submit button and invoke the API with that element instead, removing the element (if appropriate) after submission. This would ensure the form is able to access important attributes such as formAction, formEnctype, formMethod, etc from the proxy instance. It would, however, mean that the submitting element is not the custom element - the SubmitEvent.submitter property would be the proxy element.

3.) FASTButtonInstance.form.requestSubmit()

Using the same API described above, we could invoke requestSubmit() without an argument. This would cause the submitting element to be the form itself.

4.) Emit a "submit" event

The FASTButton could emit a "submit" event when the the form should be submitted.
I'm including this for completeness but I don't think this is a good option. App-authors would need to listen for this event on and then submit the form however they see fit (which would probably cause another submit event).

Proposal and notes

Unless anyone has any objections or better ideas my proposal is to implement #2 because I think it is the most behaviorally consistent with what we want. Down the line, when platform support for submit FACE components comes along we can update the element accordingly.

On a somewhat related note - a normal <button> element can be a submit button without the explicit [type="submit]. Is this something we want <fast-button> to support? Instinctually I think this is an edge-case and would bloat out the component un-necessarily but I thought I'd bring it up for discussion.

@EisenbergEffect
Copy link
Contributor

I agree with you on going with approach 2. Regarding the open question at the end, my thought would be that we require the fast-button to be of type submit in order to add the functionality. So, I'm with you on that as well I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:fast-foundation Pertains to fast-foundation bug A bug closed:done Work is finished community:request Issues specifically reported by a member of the community.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants