if (Target().IsDisabledFormControl() || !value_ ||Ana Sollano KimA way to do this that might be slightly simpler overall would be that instead of just early-returning here if there's a `HTMLSubmitButtonBehavior`, actually get the name/value from the `HTMLSubmitButtonBehavior` and append that to the form.
Then in [`FormSubmission::Create`](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/loader/form_submission.cc;l=305;drc=eaa56eeaa147cba6c18f5efcc457bd5988df377a), remove the code that adds the name/value from the behavior.
The end result is that we'd only have to handle name/value for behaviors here, not in both places (although `FormSubmission::Create` still needs to look at behaviors for other stuff).
Dan ClarkThanks for the suggestion! Let me know if I misunderstood something but I tried this out and it breaks the multi-submit-button case. `ElementInternals::AppendToFormData()` is called for every form-associated element during `HTMLFormElement::ConstructEntryList()`, so moving the behavior's name/value there causes all submit-button behaviors in the form to contribute entries, not just the clicked submitter.
Native submitters handle this with an `is_activated_submit_` flag, and both `SubmitInputType::AppendToFormData()` and `HTMLButtonElement::AppendToFormData()` check that flag before contributing.We could add a similar `is_activated_submit_` flag to `HTMLSubmitButtonBehavior` and wire it through `ConstructEntryList`. Would that be a better approach?
Ana Sollano KimAh, sorry I missed that detail. I have a slight preference for following the `is_activated_submit_` approach. I think this will be overall easier to understand if `HTMLSubmitButtonBehavior` works more similarly to normal submit buttons, rather than having the code to add the name/value pair in a different place.
Done, thanks!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |