Default triggering element should be as first

Created on 17 February 2025, 2 months ago

Problem/Motivation

After digging a bit in the issue queue, I was able to find similar issues, but not really the one I exactly had. Also, most of the fixes weren't similar to the conclusion I came up with.

Though, the complexity of how the triggering element is selected in the form API depending on all the possible scenarios, being what it is, well, complex, I'm not sure if the following fix is full proof.

Steps to reproduce

The issue is reproducible on a fresh Drupal install, using the registration form.
Only requirement: one Ajax field needs to be available upon registration, like the avatar, for example, or any other "#type" => "submit" field.

  • Go to the registration form
  • Translate the page using Google Translate "translate this page" in any other language than the page currently is in
  • Fill in the form with all required values
  • Submit the form

The form is submitted, but nothing happened, you got back to the prefilled registration form with no error message, nor a created account on the website.

My guess is that Google Translate modify the HTML of the page in such a way that the form API is not able to figure out which element was triggering the form submission.

In web/core/lib/Drupal/Core/Form/FormBuilder.php, this scenario is described as "Therefore, to be as consistent as we can be across browsers, if no 'triggering_element' has been identified yet, default it to the first button."

Proposed resolution

The first button having less chance of being the form submit, I propose to change this to the last button which has better chance to be.

🐛 Bug report
Status

Active

Version

11.1 🔥

Component

forms system

Created by

🇭🇷Croatia Aporie

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @Aporie
  • 🇭🇷Croatia Aporie

    Well, I'm already aware of a side effect which makes this method not sufficient.

    In views with exposed filters (for example the admin user view), the submit button does not have the #name set with "op" value, which prevent the form API to detect the button was clicked (even when actually clicking on it with the mouse and not hitting "Enter").

    View exposed filters offers the ability to "reset" the filter values, which button comes last.

    This ends up resetting your views filters while you want to submit a search with selected filters.

Production build 0.71.5 2024