There is no way to make a button element that can use the AJAX functionality

Hiding #18

#31 does sound like a good approach. Tagging for framework managers for their thoughts.

Once that's decided the issue summary would need to be updated.

#9 seems to be the way forward here, is this just a docs issue?

@larowlan the documentation states that #buttons don't trigger the submit handler. Do we change the documentation or update the API to meet what seems to be the original intent?

tbh I'm not sure, I don't use #type button very often

I don't think #9 fixes the issue. The problem is in the browser. When pressing the enter key, the first input element with type "submit" is triggered, instead of the actual form submit button. We should really stop using type "submit" for AJAX buttons, since they are not the primary form submit button. This is caused by the fact that Drupal\Core\Render\Element\Button always uses "submit" as the button type.

So we either need to add a new setting to allow changing the button type, maybe a key like #submit_button?

 $form['ajax_example'] = [
   '#type' => 'button',
   '#submit_button' => FALSE,
   '#value' => $this->t('My AJAX button'),
 ];

Or another render element that always uses the button type. Something like #type = 'ajax_button' (although it is not necessarily always going to be used for AJAX stuff).

Didn't see a patch to review

But was previously tagged for issue summary update which I'm sure is still needed. Plus when a patch is there will need a test case

Thanks @smustgrave :)

#39: @seanB it would seem at the moment that Drupal's take on an AJAX button is that its sole purpose is to trigger a backend handler on the form, be it the submit handler or a different method (and therefore the advice to simply turn off the submit handler).

How do we make the case for buttons which don't send anything to the backend at all? I think that would be the easiest one to get support behind. And from there we can talk about how to do it.

I've lost track of what I was trying to do when I came across this issue.

Perhaps we could make a contrib module which demonstrates the issue and will give us a measurable indicator of demand (beyond how few concerned people have found this ticket)?

Well, the list of issues in #31 is a pretty big indicator that people are struggling with problems because of the fact that it is impossible to create an <input type="button"> at the moment. Of course, we could do this in contrib, but that would mean all modules that have AJAX buttons would need a dependency on this new module to solve the issue.

Adding a flag like #submit_button to the existing button element would probably be the easiest and most developer friendly way to solve this. So I'm hoping this is a thing we could add to core.

Possible to get the issue summary update or a test case?

I think #submit_button defaulting to TRUE is a good idea here, it would be backwards compatible and less confusing than having two button elements.

This is a small API addition rather than a bug IMO, so reclassifying as a task. Also re-titled and updated the issue summary.

I am testing in the browser via the Drupal UI the current 'fix' now committed to the issue fork. I am testing using the 'simple form' in the examples project forms api module.

With the #submit_button left at default TRUE the html is:
<input class="button--primary button js-form-submit form-submit" data-drupal-selector="edit-submit" type=“submit” id="edit-submit" name="op" value="Do Not Submit!">

With the #submit_button set to FALSE:
<input class="button--primary button js-form-submit form-submit" data-drupal-selector="edit-submit" type="button" id="edit-submit" name="op" value="Do Not Submit!">

Note that the class attributes 'js-form-submit' and 'form-submit' are left unchanged. The 'type' attribute IS changed which seems the only requirement for the purposes of this issue. If anyone sees a good reason to change the class attributes please comment!

Otherwise the task of writing a failing functional test should be straightforward.

The Forms functional tests are extensive and it is tricky to work out the best place to put this test. I have arrived at the idea of creating one or two new test forms with only 2 or 3 form elements defined. Then insert a new test function (or 2) in the ElementTest test class and assert that the 'type' attribute contains 'button' or 'submit' using the 'xpath' selector type..

ElementTest::testFormElements triggers all the tests defined inside ElementTest.php. There is one failing test ElementTest::testFormElementErrors but it is outside the scope of this issue.

The test created under this ticket ElementTest::testSubmitButtonAttribute is passing.

Left comments on MR.

For some reason my local phpunit is ignoring the functional test method introduced by the merge request. Troubleshooting this now.

I'm so happy to see some traction on this and buy-in from @catch. The approach looks good to me, I think we just need to tidy a few things to grease the wheels.

Threads about the 80 character wrapping still seem to be needed.

@smustgrave @darvanen I have reacted to the code comments re the 80 character limit. Changing back to Needs review

1) Drupal\Tests\system\Functional\Form\ElementTest::testFormElements
Behat\Mink\Exception\ExpectationException: 0 elements matching xpath "//input[@type="button"]" found on the page, but should be 1.
/builds/issue/drupal-289240/vendor/behat/mink/src/WebAssert.php:888
/builds/issue/drupal-289240/vendor/behat/mink/src/WebAssert.php:441
/builds/issue/drupal-289240/core/modules/system/tests/src/Functional/Form/ElementTest.php:161
/builds/issue/drupal-289240/core/modules/system/tests/src/Functional/Form/ElementTest.php:35
FAILURES!
Tests: 1, Assertions: 74, Failures: 1.
Exiting with EXIT_CODE=1

Shows the test coverage

Also resolved the threads because they appeared to all be addressed.

I did not find anything else pending and code looks fine to me.

Going to mark it.

I read the IS, comments and the MR. I think two comments need to be improved. I did one but the other I wasn't sure what to add so setting this to needs work for those comments.

@quietone I have read the new version of the docblock comment by @trackleft2. It looks good to me. Does it 'tick the boxes' for you too? If so I would like it to be committed in place of my own docblock comment.

Believe feedback has been addressed