Submission of #required elements without #title and empty value does not display any error

Form validation does not fail, which means a form with a #required element which has no #title nor value can be submitted.

Nope. Form validation fails and the submit handler does not run. This can easily be seen by adding an + $this->assertNoRaw("The form_test_validate_required_form_no_title form was submitted successfully.", 'Validation form submitted successfully.');
to the test only patch after the first drupalPost.

+    $errors = $this->xpath('//input[contains(@class, "error")]');
+    $this->assertFieldByXPath('//input[contains(@class, "error")]', NULL, 'Error input form element class found.');

you do not use this $errors variable and also assertFieldByXPath() is the exact same as just xpath() if you call it with a NULL, but a little later in the code there's the call with FALSE -- so let's do that here as well. And let's get rid of $errors as it is not used.

Other than that, this is ready. Typically we would verify the nullity of a value with isset() but as it is not a variable the !== NULL is fine here.

This is good to go IMO.

Thanks. Committed/pushed to 8.x.

Looks like this needs a 7.x backport?

Hm. This represents a behaviour change. I'd like to run this past David first. I could see it cause seemingly random issues to crop up in contrib/custom modules, perhaps a valid use case of which might be programmatically setting #required fields behind the scenes. Then again, it seems like it's probably just exposing what ought to be happening anyway. So... yeah. Would love to get David's thoughts before commit. :)

As far as I can see, this should be safe; it makes the HTML output correctly reflect the form validation that the form API already did.

Now, watch us be totally wrong and this turn out to be the patch that breaks all of Drupal :)

In the hopes that that's not the case, I committed this to 7.x - thanks! http://drupalcode.org/project/drupal.git/commit/01f18eb (But to be safe, I'm adding this to CHANGELOG.txt and to the release notes also.)

Actually, it seems pretty odd to me that we don't display some kind of error message in this case also (in addition to the red border around the form element) but I guess that's for some other issue to solve.

In theory this could be backported, although I'm not sure it's really worth it at this point.

I found a regression with views and required exposed filters caused by this patch. In #1877678: Exposed filter gets error class without submitting it comment #6 there's a simple view to reproduce this.

Changing the patched line

if (isset($element['#parents']) && form_get_error($element) !== NULL) {
  $element['#attributes']['class'][] = 'error';
}

to the Drupal 7.16 version (pre 01f18eb540c968d1bfae7def22de558bdc208c17)

if (isset($element['#parents']) && form_get_error($element)) {
  $element['#attributes']['class'][] = 'error';
}

doesn't add the error class on this unsubmitted and thus "errorless" form.

A var_dump() of form_get_error($element) results in string(0) "", and not NULL.

Hmmm... Further investigation points to this piece of code in views/plugins/views_plugin_exposed_form.inc->render_exposed_form()

    $form_state = array(
      'view' => &$this->view,
      'display' => &$this->display,
      'method' => 'get',
      'rerender' => TRUE,
      'no_redirect' => TRUE,
      'always_process' => TRUE,
    );

...

    $form_state['exposed_form_plugin'] = $this;
    $form = drupal_build_form('views_exposed_form', $form_state);
    $output = drupal_render($form);

In this case 'always_process' => TRUE triggers form validation, which < Drupal 7.17 did throw an error, but without the error class. I now believe the patch from this issue reveiled the error in the views exposed filter plugin instead of causing it ...

Marking it as 6.x/patch again, sorry for the noise!

validation has no problems