Problem/Motivation
The media library widget has a "submit" that looks like:
$element['media_library_open_button'] = [
'#type' => 'submit',
'#value' => $this->t('Add media'),
...
'#submit' => [],
// Allow the media library to be opened even if there are form errors.
'#limit_validation_errors' => [],
];
The other buttons in the widget use '#type' => 'submit' along with custom #submit handlers to execute code after the the button has been pressed and validation has completed.
It looks like the intention here was to have a button which when submitted would do nothing (the primary action of opening the media library is carried out in the #ajax handler). However, the form submitted uses the following logic for figuring out if submit handlers should come from the form itself or the triggering element:
/**
* {@inheritdoc}
*/
public function executeSubmitHandlers(&$form, FormStateInterface &$form_state) {
// If there was a button pressed, use its handlers.
$handlers = $form_state->getSubmitHandlers();
// Otherwise, check for a form-level handler.
if (!$handlers && !empty($form['#submit'])) {
$handlers = $form['#submit'];
}
Since $handlers is [] it's falsey and the parent form submission is triggered, causing entity forms to build the entity and other components like layout builder to insert inline blocks multiple times.
Proposed resolution
I think a good resolution would be to convert this 'submit' into a 'button' instead. We aren't intending to use a submit callback or validation for opening the modal, so I think it's more appropriate.
It's possible FormSubmitter should use a NULL check instead of !$handlers but I don't think it'd be wise to make such low level changes to the FAPI system.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | 3094059-19.patch | 4.44 KB | seanb |
| #21 | interdiff-11-19.txt | 1.83 KB | seanb |
| #11 | 3094059-11.patch | 4.32 KB | sam152 |
| #11 | 3094059-11-TEST-ONLY-BUG-FROM-10.patch | 4.4 KB | sam152 |
| #11 | interdiff.txt | 1.64 KB | sam152 |
Comments
Comment #2
sam152 commentedComment #3
sam152 commentedComment #4
sam152 commentedComment #5
sam152 commentedThis seemed like the best way to test this. There are forms in contrib and layout builder which do have side effects in submit handlers that would be measurable, but with a lot of setup and dependencies.
Comment #8
sam152 commentedFixing fails.
Comment #10
oknateI'm getting "Title field is required." when opening the Media Library with the patch applied.
Steps to reproduce:
1) Add Media Library Field to Article content type.
2) Open Media Library
Expected: No validation message
Actual: "Title field is required."
Comment #11
sam152 commentedTest to reproduce #10 and a fix.
Comment #13
oknateI have tested #11, and it works fine for me. This seems like a good change. +1 for RTBC from me. But I'd like to hear from some others before marking it as such.
Comment #14
seanbThis all seems to make sense. Not sure why we didn't run into this before? I think the change from a submit button to a regular button shouldn't be a problem, but it would be good to get a +1 from the A11Y experts as well.
I also thought this might had something to do with #3003150: Media library causes validation errors when it is used in a required field of a nested form but that was about the hidden button to update the widget, not the open button. So if the A11Y maintainers are fine with the change, RTBC +1 from me.
Comment #15
seanbClosed #3047046: Media Library widget fails when used on taxonomy term form. as a duplicate of this issue.
Comment #16
andrewmacpherson commentedChanging from FAPI
#type => submitto#type => buttonmakes no changes whatsoever to the HTML. Both of those FAPI snippets emit the same HTML:<input type="submit"There isn't any change here at all as far as the HTML source, DOM, or accessibility tree is concerned.
+1 from me.
Comment #17
phenaproximaBefore I can RTBC #11, I have a question -- the test-only patch removes #limit_validation_errors from the open button, but the passing patch doesn't. What's up with that?
Comment #18
phenaproximaNit: This should have TRUE as the third argument.
We probably need to explain this a bit better and go into more detail about what this assertion covers, lest we accidentally remove it. A few @see comments couldn't hurt.
Comment #19
matthieuscarset commentedTested on
8.7.8and it unfortunately does not apply.FYI this one-line patch from https://www.drupal.org/project/drupal/issues/3047046 works on 8.7.8
Comment #20
phenaproximaOkay, that means we will need to reroll this for backport. Thanks for testing it!
Comment #21
seanbFixed #18.
Comment #22
phenaproximaThanks, @seanB! This looks good, RTBC on green.
Comment #23
phenaproximaOn second thought, sending back to NR for #17. Please feel free to restore RTBC once testbot is green and the question I posed is answered.
Comment #24
seanbFrom https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...
So we need the limit validation errors to make sure the validation is not triggered for the button either.
Comment #25
phenaproximaMakes sense.
Comment #26
sam152 commentedThe test only patch removed
#limit_validation_errorsto prove that the new test coverage covered the bug reported in comment #10.Thanks for reviews and fixes 👍
Comment #29
webchickCrediting folks from the other issue @ #3047046: Media Library widget fails when used on taxonomy term form..
Comment #33
webchickGreat find, great fix, and thanks for the test coverage!
Committed and pushed to 9.0.x; 8.9.x; 8.8.x. Thanks a lot!