SearchProvider rebuilds the search index for every query

[avinxshKD]

Problem

SearchProvider fetches and rebuilds the full Fuse search index every time the submitted search term changes. Entering multiple queries causes repeated requests for the same locale JSON and repeatedly performs the expensive flattening and indexing work.

Because requests are not cancelled, an older locale response can also finish after a newer one and overwrite the active search index.

Steps to reproduce

1. Open /search/ and the browser network panel.
2. Submit multiple search terms.
3. Observe repeated requests for the same file under /search-indices/.

Expected behavior

• Fetch and build the Fuse index only when the locale changes.
• Reuse that index for subsequent submitted searches.
• Clear the previous locale's index while its replacement loads.
• Abort an in-flight index request when the locale changes or the component unmounts.

File

src/components/SearchProvider/index.tsx

[avinxshKD]

@davepagurek @ksen0 what do you think of this? Can i work on this if this makes sense

[ksen0]

Thanks for spotting this and the reminder @avinxshKD ! the title of the issue seems to not match the body? But the description is on the website. I will transfer it there.

Typing "createVector" = 13 requests to the same en.json.

Could you share a video please? I was not able to reproduce this on beta site, main site, or dev environment. I consistently observe the searchProvider / en.json call only on pressing Enter.

There's also a race condition, no AbortController means a slow response
for "col" can resolve after "color" and overwrite the results.

This would be good to fix though I'm not able to induce it without the excessive calls to searchProvider

I'm happy for you to work on this but before PR it would be great to document more what the problem is exactly.

[rushdarshan]

Hey, just to follow up on @ksen0's note about the title/body mismatch — the body describes a legitimate SearchProvider performance issue, but the title references a separate bug in CodeEmbed/frame.tsx that isn't documented anywhere in this thread.
I looked into the frame.tsx postMessage handler and the vulnerability is real. Around line 56:

typescriptwindow.addEventListener("message", event => {
  const scriptExists = !!document.getElementById("p5ScriptTagInIframe");
  if (!scriptExists && event.data?.sender === '${cdnLibraryUrl}') {
    const p5ScriptElement = document.createElement('script');
    p5ScriptElement.textContent = event.data.message;
    document.head.appendChild(p5ScriptElement);
  }
});

event.data.sender is caller-controlled and can be spoofed. Without an event.origin check, any origin can execute arbitrary code in embedded sketches (XSS vulnerability)
Fix:

typescriptconst allowedOrigin = new URL(cdnLibraryUrl).origin;

window.addEventListener("message", event => {
  const scriptExists = !!document.getElementById("p5ScriptTagInIframe");
  if (
    !scriptExists &&
    event.origin === allowedOrigin &&
    event.data?.sender === cdnLibraryUrl
  ) {
    const p5ScriptElement = document.createElement('script');
    p5ScriptElement.id = "p5ScriptTagInIframe";
    p5ScriptElement.textContent = event.data.message;
    document.head.appendChild(p5ScriptElement);
  }
});

Should this be tracked as a separate issue so both bugs get proper attention? Happy to open a PR for the frame.tsx fix.

[avinxshKD]

Hey @rushdarshan, thanks for checking this out! I’m already working on this issue
Thanks

[avinxshKD]

@ksen0 sorry was busy with exams

Yeah sure I'll document about the problem and update you soon

[avinxshKD]

@ksen0 rechecked this today, still partly valid.

search side is still doing too much work per keystroke (refetch + rebuild fuse, no debounce, no abort), so perf/race concerns are still real.

on embed side: postMessage("*") is still there and should be tightened, but the “p5.sound never loads” part looks outdated now since sound gets passed in when enabled.

opening a PR for the search fixes + origin