You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The JS that pops up the search modal triggers on any form that is submitted which has an input named s. This can interfere or be triggered by embed forms from third-parties (e.g. ActiveCampaign sign up forms).
Steps to reproduce
On a post/page add a custom HTML block with the following markup:
On the frontend, click the Test button. Observe that the search modal pops up and the form is not submitted:
Screen.Recording.2026-03-11.at.2.27.15.PM.mov
This is a simplified example demonstrating the issue. With third-party embedded forms, the user can't really customize what fields the form requires, so if it uses an s field within it, there doesn't seem to be a workaround.
As a proposed solution that I think would have no side effects, the JS form submit listener should not listen to forms that go to third-party domains. It should only listen to forms that submit to the site itself.
Site owner impact
Fewer than 20% of the total website/platform users
Severity
Moderate
What other impact(s) does this issue have?
Individual site owner revenue
If a workaround is available, please outline it here.
For forms that the user controls, they could modify it to not use an input named s.
For third-party embedded forms, no workaround is possible as far as I can tell, because the forms are generated by a third-party script e.g.
Impacted plugin
Search
Quick summary
The JS that pops up the search modal triggers on any form that is submitted which has an input named
s. This can interfere or be triggered by embed forms from third-parties (e.g. ActiveCampaign sign up forms).Steps to reproduce
Screen.Recording.2026-03-11.at.2.27.15.PM.mov
This is a simplified example demonstrating the issue. With third-party embedded forms, the user can't really customize what fields the form requires, so if it uses an
sfield within it, there doesn't seem to be a workaround.As a proposed solution that I think would have no side effects, the JS form submit listener should not listen to forms that go to third-party domains. It should only listen to forms that submit to the site itself.
Site owner impact
Fewer than 20% of the total website/platform users
Severity
Moderate
What other impact(s) does this issue have?
Individual site owner revenue
If a workaround is available, please outline it here.
For forms that the user controls, they could modify it to not use an input named
s.For third-party embedded forms, no workaround is possible as far as I can tell, because the forms are generated by a third-party script e.g.
Platform (Simple and/or Atomic)
Atomic