Search/autocomplete not initializing correctly after jQuery is deferred

[Ashish-Rautela]

Description

Search/autocomplete is currently not initializing correctly on the main branch of Music Blocks. There is no obvious UI error, so this issue can easily go unnoticed, but the search functionality does not work as expected.

I investigated this using git bisect and traced the first occurrence to commit 01cee2a (PR #4828 ), which introduced deferred loading of jQuery for performance and accessibility improvements. The PR itself is valid, but it exposed fragile assumptions in the existing search initialization logic.

Expected Behavior

Search/autocomplete should initialize correctly on page load.
Typing in the search field should show suggestions and allow selecting blocks as before.

How to Reproduce

• Check out the current main branch.
• Open Music Blocks in a browser.
• Try using the search/autocomplete input.
• Observe that search suggestions do not appear and search does not function.
• Console log Errors:
  Uncaught ReferenceError: $ is not defined

This occurs because search initialization relies on global $ and inline execution order.

Environment:

Operating System: Windows 10
Browser : Chrome
Version of Software/Project: current main branch

Checklist

• I have read and followed the project's code of conduct.
• I have searched for similar issues before creating this one.
• I have provided all the necessary information to understand and reproduce the issue.
• I am willing to contribute to the resolution of this issue.

Thank you for contributing to our project! We appreciate your help in improving it.

I also opened a small PR that temporarily restores non-deferred jQuery to unblock search while a proper refactor of search initialization is discussed. That PR is intentionally marked as a temporary workaround, not a long-term solution.

[saurabh24thakur]

Hi @Ashish-Rautela, I've reproduced the Uncaught ReferenceError: $ is not defined locally. Since the deferred jQuery loading is causing the search initialization to fail, I'm working on a fix that wraps the search logic in a DOMContentLoaded listener or ensures it executes only after jQuery is fully loaded, instead of just reverting the defer. I'll raise a PR shortly.

[Ashish-Rautela]

Hi @saurabh24thakur , thanks a lot for taking a look and reproducing the issue 🙌
Just to add some context from my side:
I did try a few approaches along the lines of initializing search after DOMContentLoaded and after jQuery availability, but I kept running into issues because doSearch currently mixes UI initialization and execution and relies on some implicit timing/state assumptions tied to the Activity lifecycle. That made it hard for me to land a safe minimal fix without refactoring that part.
That said, your approach of ensuring the logic runs only after jQuery is fully loaded sounds like the right direction for a proper fix 👍. Happy to review or help test your PR once it’s up, and I’m glad this is being addressed without reverting the deferred loading.

[saurabh24thakur]

Hi @Ashish-Rautela, thanks for the context!

I've just raised the PR here: [ https://github.com//pull/4977]

You were right about the timing issues. I discovered that activity.js actually already handles the search initialization lazily (when the search widget is focused). The inline script in index.html that was crashing was trying to initialize it too early and was actually redundant.

My fix simply removes that problematic inline script. This resolves the ReferenceError and keeps the search working without needing to revert the deferred loading. I'd appreciate your review!