Search: fix uncaught URIError from malformed query params crashing Instant Search#50806
Search: fix uncaught URIError from malformed query params crashing Instant Search#50806interlineae wants to merge 2 commits into
Conversation
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
Code Coverage SummaryCoverage changed in 1 file.
|
robfelty
left a comment
There was a problem hiding this comment.
Looks good with one change. I don't think we should try to do the bare % replacement, because it results in confusing behavior, where it works sometimes and not others, in a way that is likely to make debugging more difficult in the future. I think catching the error is sufficient.
… failure Per review feedback (#50806): partial-recovery via a bare-% sanitization regex was inconsistent and hard to debug — a merge tag like %ABTEST% would still throw (A and B look like hex digits) while %DONOR% would recover fine, depending on incidental letter content. Instead, any value that fails to decode now uniformly falls back to an empty string, regardless of what follows the %. This is already a normal, well-supported state (the same as a user clearing the search box), keeps the key present in the query object so a malformed search term still registers as an active query, and is always safe to re-encode later. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Fixes #50709
Proposed changes
decodeURIComponent()in Instant Search's vendored query-string decoder (query-string-decode.js) against malformed percent-encoding (e.g. a stray%, an unresolved email merge tag like%DONOR%, or invalid escapes like%zz), which previously threw an uncaughtURIErroron every page load and crashed Instant Search's initialization, leaving the page blank.%not starting a valid%XXescape is escaped to%25) and then decoded, so the value is recovered as literal plain text (e.g.%DONOR%decodes to the literal string%DONOR%) instead of throwing. This lets Instant Search keep treating the value as an active search term (e.g. showing its own "No results found" state) rather than silently dropping it or falling back to the site's classic search page.%XXescapes but decodes to an invalid byte sequence (e.g. a truncated UTF-8 sequence), that key is dropped rather than kept as a raw value — keeping a still-encoded raw string would get double-encoded (and corrupted) the next time the query object is round-tripped throughqss'sencode().Related product discussion/links
URIErrorand blanks the page #50709Does this pull request change what data or activity we track or use?
No.
Testing instructions
https://yoursite.com/?s=%MAhttps://yoursite.com/?s=%zzhttps://yoursite.com/?test=%MALFORMED%URIError: URI malformed.s(search term) param, the Instant Search overlay opens showing "No results found" for the literal text (e.g.%MA). For a malformed bystander param unrelated to search, the page loads normally and that param is otherwise unaffected.pnpm test-scripts(fromprojects/packages/search/) — includes new regression tests insrc/instant-search/external/test/query-string-decode.test.js.