$element['#id'] should respect $element['#attributes']['id'] if it's set, since that is often used to specify the HTML ID

I see this already fixed in the most recent 7.x-dev from 2012-09-14.

I just tested this on the current (as of Oct 11, 2012) dev version and the issue is not fixed.

The reason why this happens is because form_builder() sets $element['#id'] regardless of $element['#attributes']['id'].
Later in the forms processing theme_form_element_label() uses $element['#id']to set the label's for attribute value.

But the theme functions for textfields, selects,... ( e.g. theme_textfield() ) only use $variables['element']['#attributes']['id']

So we can have to different id values that are being used in different places.

In order to prevent different id attributes we synchronise $element['#id'] and $element['#attributes']['id'] in form_builder().

According to the current Forms Api documentation:

#id
Description: Internal. Used to populate form elements' id property. In rare cases, you can set this value yourself on a form element, to override the default setting.

...we should not use #id, so we let $element['#attributes']['id'] override $element['#id'] if set.

Old code:

if (!isset($element['#id'])) {
  $element['#id'] = drupal_html_id('edit-' . implode('-', $element['#parents']));
}

New code:

if (isset($element['#attributes']['id'])) {
  $element['#id'] = $element['#attributes']['id'];
}
elseif (!isset($element['#id'])) {
  $element['#id'] = drupal_html_id('edit-' . implode('-', $element['#parents']));
}

Like @dawitti I just tested on the latest D7 dev and it's still there.

This issue is also available for Drupal 8, so tagging as D8.

@dawitti, as marked in the comment "In rare cases, you can set this value yourself on a form element", why do you force the override of $element['#id'] if it is already set ?

Here i corrected that patch..

What did you corrected ? Have you found a case where $element['#id'] were not properly set ?

According to the first check on $element['#id'] a line above, the NULL value could not be assigned to $element['#id'] in the second ternary.

if (!isset($element['#id'])) {
  $element['#id'] = isset($element['#attributes']['id']) ? drupal_html_id($element['#attributes']['id']) : !isset($element['#id']) ? drupal_html_id('edit-' . implode('-', $element['#parents'])) : NULL;
}

Your patch #6 is correct.
The form element rendered correctly. Still finding why its fails

This still a concern in D8? Unassigned issue too.

I'm making the title more general, given what the patch is trying to accomplish. (There are other parts of Drupal that make decisions based on #id too.)

Not sure if there are other places in the codebase this would need to be changed as well.

-    $element['#id'] = drupal_html_id('edit-' . implode('-', $element['#parents']));
+    $element['#id'] = isset($element['#attributes']['id']) ? drupal_html_id($element['#attributes']['id']) : drupal_html_id('edit-' . implode('-', $element['#parents']));

I would think the first drupal_html_id() call shouldn't be there - if ['#attributes']['id'] is set shouldn't that just be used as is?

Is this really referring to 8.1.x? I only find the issue in Drupal 7, shouldn't the version of the issue be changed to 7.x-dev?
Regarding the drupal_html_id() removal in patch #6, I've attached a new one for 7.x-dev. But a question remains ... what if, in a custom module, the ID is erroneously misspelt and it doesn't conform to the standard?

I am not able find this issue any more with Drupal 8.x So I changed to Drupal 7.x-dev,

But a question remains ... what if, in a custom module, the ID is erroneously misspelt and it doesn't conform to the standard?

Then Drupal will probably output an invalid HTML ID. But isn't that what it will do already in that case? I'm not sure it's related to this issue, or that the code should try to change an ID that was specifically set.

I am not able find this issue any more with Drupal 8.x

For Drupal 8 this code is in https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Form!FormBuilder....

@David_Rothstein thanks for pointing out where the problem was.
I've attached a patch for 8.1.x

I've attached a new patch, to fix the failing tests.

The problem that I found, is that in some places the ['#attributes']['id'] is an array, like bellow:

$element['#attributes']['id'] = array('views-display-top');

in renderDisplayTop() in ViewsEditForm.php
Is this ok?

I'm wondering whether the alternative implementation could be to reference $element['#id'] from $element['#attributes']['id']
so multiple code paths changing it would not just ignore each other.

Patch 27 works for me on Drupal 8.8.1

Upon further review, this doesn't work when used with Ajax. The label 'for' attribute is regenerated but the input is left as defined.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.