Antibot not working if webform is rendered in a block

I've just tried to reproduce your issue and couldn't find any problem. To begin with I couldn't find the

Checkbox checked to protect all webforms using anitbot.

Running both webform & antibot on their latest dev snapshot I was able to successfully submit a webform both on its dedicated page and when it was exposed as a block. I did have to add "webform_submission_*" onadmin/config/user-interface/antibot to make antibot protect the webform forms.

The only thing I found that could be related is a fixed (but not yet released in a stable release) issue #2888403: Webform Ajax and Antibot not working together. So I would suggest you to try antibot dev snapshot. If it does not work for you there, then we will need a more comprehensive instructions from you.

By some pure luck I did come access the checkbox nimoatwoodway was speaking about. So teased by the presence of the checkbox I gave it another shot and now I do confirm the bug. My original testing did not identify the problem because I was testing my block on the same page where the webform was also the main content and due to the nature of the bug it lead me into wrong believe.

I do confirm either enabling the checkbox in the webform 3rd party settings or using the placeholder "webform_submission_*" reproduces the error as long as there is no webform as main content, i.e. only in a block. The problem is that pre_render function antibot_form_pre_render() does not get called for not yet identified reason when the webform is served from a block (but it does get called when it is served as the main content).

I will investigate this one and will post when I have something new.

hm.. seems like 2 lines of code will do it. Though I do wanna see what testbot says.

The problem was within the 'webform' render element (Drupal\webform\Element\Webform). Its #pre_render callback was merging (+) the element itself with the built form array. I think such merge sooner or later would introduce to side effects, because some properties would collide between the element and the form array. This particular bug occurs because the #pre_render of the form do not make it into the produced result (the element already has some #pre_render).

Noticeably, another important property is #type which was getting lost. So it was returning a renderable array of form but with #type => 'webform'.

I solved it by nesting the form as a child.

The concept of a dedicated 'Webform' element was inspired by the 'View' element (\Drupal\views\Element\View).

The 'Views' element does not merge the render view with the $element instead it sets a $element['view_build'] property.

I think the only change we need to make is to use $element['webform_build'] instead of $element['form'].

I don't expect there to be a lot of people altering this markup but we should create a very sort change notice.

Gotcha. In this patch I rename it. (looking at the source code of the View render element, I find inline comments that support my thinking :) )

Let's see if mr. nimoatwoodway has any feedback. Or should I commit it straight?

Here is the change notice.
https://www.drupal.org/node/2943271

@bucefal91 We both agree that this tweak is required so we should move ahead. I suspect it might fix other outstanding bugs and issues.

Please review and publish the change notice and then commit the patch.

nimoatwoodway - receive our congratulations!!! :) That's a small present then webform module maintainers do on this occasion - solving a bug for you :) Enjoy the honeymoon!

cutting to the business - change record published, code is committed & pushed.