Submitted custom form lands on search results page

I can't see/find a way to reproduce this issue, can I get some more background information about you set up ? Or maybe we could try to write a test for that ?
How does custom form look like? What's the "Search results page" , which module is providing it ?

Yes! We didn't have this problem, but we did have a problem with session validation and errors. Turns out to be the same issue.

Here's a quick run-down:

Each part (block) on the page is cached separately, so when someone visits the homepage and that gets cached, Drupal also just pulls the search form from its cache for other pages instead of rendering it from scratch.

If rendering the whole page from scratch, Drupal uses unique IDs in every form. One's submit button has the id #edit-submit, another gets #edit-submit--2, the other #edit-submit--3. But due to the caching behavior with reusing existing blocks, we end up with:

1. If you visit the homepage, which just has the search form, its button gets #edit-submit.
2. When you visit the contact page, which has 2 forms that need to be rendered, the Sign Up and contact form, Drupal uses ids #edit-submit and #edit-submit--2. But the cached search form also ends up in the header with an id of #edit-submit too.

The simple_recaptcha module does something quirky. When you click the submit button it runs some javascript to get a token from the reCAPTCHA service, which is fine, but then it has to re-click the submit button, and it does it by looking up the button by ID again. Looking up by ID gives the first element with that ID, the search form's submit button.

We've found the attached patch fixes us up.

This seems to be an outcome of caching issues indeed, can be easily reproduced when following steps described in #1852090, or trying to reproduce logic of following patch.

Proposed solution can deal with the issue, but it can bubble with buttons and remove too much data attributes, also the jQuery code will still remain invalid and unreliable, as described in jQuery docs:

Each id value must be used only once within a document. If more than one element has been assigned the same ID, queries that use that ID will only select the first matched element in the DOM. This behavior should not be relied on, however; a document with more than one element using the same ID is invalid.

I'd like to propose a bit different approach, which will get rid of querying submit elements by ID attribute:

const $currentSubmit = $('#' + submitHtmlId);

and use a bit of data-* attributes and form IDs instead, those are unique even when caching gets into some troubles.

Please give a try to this patch which updates JS library for both reCAPTCHA types :_)

Looks good to me: both v2 and v3 versions only trigger the protected form submit button.

This is now committed to dev branch , new release will follow soon,
thanks every1 !