Inline errors not shown for details elements

We also need to modify the classy template, that's the one themes end up using. In the attached patch.

So, the container preprocess and template file can easily get the same treatment, but what makes container different is the fact that it's a generic theme/render element, not a form element. Is it weird for it to have errors in that case? Either it isn't, and we make the change, or it is, and we find a way to forbid setting errors on it, while communicating to people writing widgets and forms that they need to use a details element instead.

Okay, opened #2560467: Inline Errors not shown for container elements for the contaienr element.

We need to change the form-error-message class to form-item--error-message, to sync with #2501903: inline form errors classnames to follow namestandard.

Would also be great to figure out a test.

/**
 * Builds a simple form to test the #group property on #type 'container'.
 */
class FormTestGroupContainerForm extends FormBase {

Looks like we're reusing an unrelated form? Why not add our own (+ route)? FormTestDetailsForm for example?

Thank you, JeroenT and StryKaizer. You are making my day.

+    $form['meta'] = [
+      '#type' => 'details',
+      '#title' => 'Group element',
+      '#open' => TRUE,
+      '#group' => 'container',
+    ];

The #group no longer means anything, so we can remove it. And the #title can be "Details element".

Other than that, this looks ready for an RTBC.

We're good to go. Thanks, everyone.

If in the mood for more related work, the next one is: #2027059: Improve the documentation of WidgetBase::errorElement() for mapping violation property paths to form elements.

I added the div because fieldset.html.twig in the same folder has one:

  <div class="fieldset-wrapper">
    {% if errors %}
      <div>
        {{ errors }}
      </div>
    {% endif %}

Let's ask a themer.

Thank you, Morten.

Alex, I'll add a screenshot ASAP.

I used the provided form.

As I said, the error repeated on all elements is the result of a different bug (#2509268: Inline errors repeated on child elements in module uninstall form), and will actually be gone at one point.
The expected behavior is for the error to be shown on top of the form.

namespace Drupal\broken_form\Form;

use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;

class BrokenForm extends FormBase {

  /**
   * {@inheritdoc}
   */
  public function getFormId() {
    return 'broken_form';
  }

  /**
   * {@inheritdoc}
   */
  public function buildForm(array $form, FormStateInterface $form_state) {
    $form['address'] = [
      // The error set for $form['address'] shows as expected on #type = 'fieldset',
      // but not on #type => 'details'.
      '#type' => 'details',
      '#title' => 'Address',
      '#open' => TRUE,
      // #tree => TRUE is what triggers the "all children get the parent error"
      // bug.
      '#tree' => TRUE,
    ];
    $form['address']['country_code'] = [
      '#type' => 'select',
      '#title' => 'Country',
      '#options' => ['FR' => 'France', 'RS' => 'Serbia'],
    ];
    $form['address']['city'] = [
      '#type' => 'textfield',
      '#title' => 'City',
    ];
    $form['address']['postal_code'] = [
      '#type' => 'textfield',
      '#title' => 'Postal code',
    ];
    $form['address']['submit'] = [
      '#type' => 'submit',
      '#value' => 'Submit',
    ];

    return $form;
   }

  /**
   * {@inheritdoc}
   */
  public function validateForm(array &$form, FormStateInterface $form_state) {
    $form_state->setError($form['address'], 'Everything is wrong.');
  }

  /**
   * {@inheritdoc}
   */
   public function submitForm(array &$form, FormStateInterface $form_state) {
     drupal_set_message('Good job!');
   }
}