Nested form tag in views forms

Well this seems to work because it is already a form, and #theme => form is a #theme_wrapper for
#type => form
by default. Not totally sure about the removal of the #children thing in the preprocess but feels right. Needs manual testing for sure.

No need to apologize, you are right it does:) It's just a chore sometimes when bugs are easy to fix. And if you see my tests you'd regret asking for them, muahaha:D

I've got the assertion ready. Just need to build a view like admin/content that has the nested form.

    // Ensure we don't have nested form elements.
    $xpath = $this->xpath('//form//form');
    $this->assertFalse($xpath, 'The views form element is not nested.');

There doesn't seem to be any Views Form Tests in core. May consider creating a new one ViewsFormTest

Maybe the type of form is wrong, I can still preproduce this by view source on the admin/content page.

Also that test is incorrect, if you look at that output it doesn't really create one. But @dawehner let me know "Bulk Update" test may work so I'm going to try that.

Apparently my xpath() is crap or it just sucks at finding nested form tags... wrote a regex instead.

For the doubters of the xpath not working.

    $elements = $this->xpath('//form//form');
    $this->assertFalse($elements, 'Xpath no nested forms.');

the xpath could be wrong... but I wanted to find also /form/div/form

@cweagans thanks for the suggestion, didn't think to use that package, will give it a try. see #12 and #10 for why regex was used, because xpath didn't work as expected and I wanted to get something working and use something I know. But I'll give that package a try.

@xjm I know we want to remove it as it's one of the remaining "why is this being used" legacy function calls, and removing it helped resolve the problem.

1. It helped cause this issue it seemed: #2119881: views BulkFormBase shows 'Apply' button twice
2. And apparently I helped move it from the theme function here #1912600: Remove theme_views_form_views_form in favour of a prerender callback.
3. And it originally came from the theme function when views was added to core a626abb - Add the 7.x-3.x Views branch. (2012-10-07 17:51:56 -0400)<merlinofchaos>

function theme_views_form_views_form($variables) {
...
  // Render and add remaining form fields.
  return drupal_render_children($form);
}

And we've removed all the other instance of that in core, so I think it's safe to remove.

@cweagans Good news: Mastermind/html5 does a better job creating the DOMDocument for HTML5 and ignores errors(where SimpleTest just suppresses errors).
This means I can traverse the DOMDocument it creates much better than the one that SimpleTest creates. And I could test this problem with this:

$html5 = new HTML5();
$dom = $html5->loadHTML($html);
$form_list = $dom->getElementsByTagName('form');
foreach ($form_list as $node) {
  $nested_form_list = $node->getElementsByTagName('form');
  if ($nested_form_list->length) {
    print "Found nested form: " . $nested_form_list->item(0)->getAttribute('id') . "\n";
    break;
  }
}

Bad news: XPath doesn't work with HTML5, so the DOMXPath() basically finds nothing. Seems to be documented in this issue: https://github.com/Masterminds/html5-php/issues/12

HTML5 doesn't support them the way XML does.

To see the work I did around this try it out for your self, maybe I made a mistake(very likely):
https://gist.github.com/joelpittet/62e7e5bd83e793c599c2

Output: php < index.php

--------------------
WebTestBase
--------------------
Forms by tag name: 3
Form: form-1

Form: form-2
1
Form: form-3
1
Simple XML traverse: 0
//div//div: 1
//form: 3
//form//form: 0
//form/form: 0
--------------------
MasterMind\HTML5
--------------------
Forms by tag name: 3
Form: form-1
1
Found nested form: form-2
//div/div: 0
//form: 0
//form//form: 0
//form/form: 0
Simple XML traverse: 1
//div//div: 0
//form: 0
//form//form: 0
//form/form: 0
--------------------
Error Handler
--------------------
Caught error: Unexpected end tag : form in Entity, line: 10

So with that, I'm going to stick with my simple regex because it's still more to the point and straight forward to read than loading the external library just to manually traverse, IMO.

Looks like a random failure. I applied to patch and ran "Drupal\user\Tests\UserPasswordResetTest" locally and it passed.