In community.wanikani.com, opening any links to topics with Japanese in the fully qualified URL stopped working when opening them in a new tab or directly copying and pasting the link. Clicking the link to navigate within the same tab still works.
For example, opening this link in a new tab should navigate to
If the link happens to match exactly, it works fine. But of course with topic renames this is often not the case.
I also tried to reproduce on try.discourse.org, but on that install Japanese characters never get added to the URL even when included in the topic title. I’m not sure why that’s the case, but without that happening I can’t demonstrate the bug there.
sigh It looks like it might be yet another Chrome bug. It works fine for me in both Firefox and Edge. Weirdly it works the first time in an incognito window, but then fails the second time. Same thing after clearing site cache/cookies and restarting my computer.
Would you mind checking in Chrome to confirm if it’s an issue there in general and not just a problem for me? Just be sure to try to open the page multiple times since the first one seems to work fine. I appreciate the help!
Still with Chrome? Just want to be sure before reporting it to them. I assume nothing changed related to this recently on Discourse? (Regardless, this would probably still be a Chrome issue since it just happens there, even if something did change on Discourse.)
Well scratch that. It started happening again today. I have no idea how it got fixed for a bit.
Since this might take a while, I’d be open to workarounds for now. I mentioned in the OP about how on try (and I checked here on meta too) the Japanese characters never get added to the URL, effectively circumventing this issue. Is that a site or category setting that I can talk to my site admin about? Any other suggestions for a workaround besides that?
I have dig into our codebase and looks like the error is kinda simple, but I would like to verify my assumptions.
We have a site setting named slug_generation_method which must be changed from the default ascii value to encoded in order to trigger this bug. When you change this site setting, we clear all slugs and generate those again.
What I don’t understand is why when the site setting is set to “encoded” we generate a slug like this:
The raw slug from the table is returned in the Location header 301 response when a topic slug doesn’t match, and IMO we should return a valid URL in there.
So are you saying the URL itself would show the encoded version? Or just that the redirect would internally handle it by using the encoded version? Either way, getting this to “just work” and not rely on browser quirks would be great.
No, as denoted by the open topic in the bug category here
@sam I took a look on this again today and there are two ways to go about it:
Store an actual encoded slug in the slug column when the slug generation setting is set to encoded. Make a migration to clear out all current slugs when using encoded slugs so they regenerate over time properly.
Keep the current UTF-8 slug and patch it on the fly when sending it out in a header for 301 redirect.
IMO 1 is “more correct” and it will make harder to pass the raw slug to a client. However, just patching the slug generator wasn’t enough as the browsers gets an encoded URL on 301 redirect but decodes it for the next request our slug comparison fails and redirects again. That means I will also need to patch the slug comparison method in the topics controller, and maybe other places.