New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix string decoding in the frontend #4144
Conversation
Signed-off-by: Olga Bulat <obulat@gmail.com>
Signed-off-by: Olga Bulat <obulat@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite sure I understand all the logic here with the regex replacement, but I've confirmed I'm not able to reproduce the issue locally!
@@ -1,3 +1,16 @@ | |||
const double_backslash_escaped_regex = /(\\x)([\da-f]{2})|(\\u)([\da-f]{4})/gi | |||
const no_backslash_escaped_regex = /(?<!\\)(u)([\da-f]{4})/gi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we not need to have a similar case for \x
characters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that kind of encoding/decoding error never happened :)
Based on the high urgency of this PR, the following reviewers are being gently reminded to review this PR: @zackkrida Excluding weekend1 days, this PR was ready for review 4 day(s) ago. PRs labelled with high urgency are expected to be reviewed within 2 weekday(s)2. @obulat, if this PR is not ready for a review, please draft it to prevent reviewers from getting further unnecessary pings. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, meant to have already approved this. LGTM.
Fixes
Fixes #4125 by @obulat
Description
This PR updates the
decode-data
function to not convert the character combinations that are not URI-encodable.Some tags contain incorrectly encoded tag names without the backslash for u-encoded characters. We compensate for that in the frontend by converting them correctly to unicode characters. However, there's an edge case where the combinations of characters such as
udada
are considered as incorrectly-encoded sequence of characters, but the result is a symbol that is not valid in a URL, so when we try to create a tag URL from it in a single result page, the page shows an error.We will move the tag cleanup from the frontend to the data cleanup process in the future, but for now, to fix the Nuxt server error page1, we need to add a hot-fix in the frontend.
Update: this will also fix the incorrectly decoded titles and other decoded strings. See, for instance, https://openverse.org/image/9cda415c-c4d1-4650-9e1e-0f92b5f8d772?q=ciudada : the title and the attribution have incorrectly displayed characters that replace "udada" in the word "ciudada".
Testing Instructions
Run the app using
just frontend/run dev:only
Open http://localhost:8443/image/076a0436-1d9e-449a-a224-01301f4d8c8e
You should see the page loaded correctly.
Go to http://localhost:8443/image/9cda415c-c4d1-4650-9e1e-0f92b5f8d772?q=ciudada . You should not see un-printable characters as you do in prod.
Checklist
Update index.md
).main
) or a parent feature branch.Developer Certificate of Origin
Developer Certificate of Origin
Footnotes
udada
in "ciudada" in tags for item https://api.openverse.engineering/v1/images/076a0436-1d9e-449a-a224-01301f4d8c8e/ causes a Nuxt server error: https://openverse.org/image/076a0436-1d9e-449a-a224-01301f4d8c8e ↩