[Platform-provided behaviors] Prevent duplicate form entries [chromium/src : main]

0 views
Skip to first unread message

Ana Sollano Kim (Gerrit)

unread,
1:28 PM (3 hours ago) 1:28 PM
to Nate Chapin, Dan Clark, Mason Freed, Leo Lee, Chromium LUCI CQ, chromium...@chromium.org, android-bu...@system.gserviceaccount.com, gavinp...@chromium.org, blink-re...@chromium.org, loading...@chromium.org, blink-rev...@chromium.org, blink-revie...@chromium.org, dominicc+...@chromium.org, blink-...@chromium.org
Attention needed from Dan Clark

Ana Sollano Kim added 2 comments

Patchset-level comments
File-level comment, Patchset 5 (Latest):
Ana Sollano Kim . resolved

This is ready for another look 😊

File third_party/blink/renderer/core/html/custom/element_internals.cc
Line 557, Patchset 2: if (Target().IsDisabledFormControl() || !value_ ||
Dan Clark . resolved

A 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).

Ana Sollano Kim
Thanks 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?

Dan Clark

Ah, 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.

Ana Sollano Kim

Done, thanks!

Open in Gerrit

Related details

Attention is currently required from:
  • Dan Clark
Submit Requirements:
  • requirement satisfiedCode-Coverage
  • requirement is not satisfiedCode-Owners
  • requirement is not satisfiedCode-Review
  • requirement is not satisfiedReview-Enforcement
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
Gerrit-MessageType: comment
Gerrit-Project: chromium/src
Gerrit-Branch: main
Gerrit-Change-Id: Ic5f7ec103d90fe1fd6ba8ed11ded9bd1b04b9c84
Gerrit-Change-Number: 7773038
Gerrit-PatchSet: 5
Gerrit-Owner: Ana Sollano Kim <anso...@microsoft.com>
Gerrit-Reviewer: Ana Sollano Kim <anso...@microsoft.com>
Gerrit-Reviewer: Dan Clark <dan...@microsoft.com>
Gerrit-Reviewer: Mason Freed <mas...@chromium.org>
Gerrit-CC: Leo Lee <leo...@microsoft.com>
Gerrit-CC: Nate Chapin <jap...@chromium.org>
Gerrit-Attention: Dan Clark <dan...@microsoft.com>
Gerrit-Comment-Date: Wed, 29 Apr 2026 17:28:22 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Ana Sollano Kim <anso...@microsoft.com>
Comment-In-Reply-To: Dan Clark <dan...@microsoft.com>
satisfied_requirement
unsatisfied_requirement
open
diffy
Reply all
Reply to author
Forward
0 new messages