Skip to content
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 browsing for non-ascii entity URI under Safari #78

Merged
merged 1 commit into from Jun 24, 2015
Merged

Fix browsing for non-ascii entity URI under Safari #78

merged 1 commit into from Jun 24, 2015

Conversation

ghost
Copy link

@ghost ghost commented Jun 21, 2015

Previously, browsing entities with non-ascii characters in their URI
under Safari wouldn't work. Directories would be empty, songs wouldn't
be added. I haven't tried it, but this behavior seems to be common to
Webkit-based browsers, so Chrome would be affected too.

This turned out to be because Safari normalizes all unicode strings to
NFC, breaking the link with MPD-spewed URIs, which are in NFD.

An obvious fix would have been to normalize all URIs to NFD, but
unfortunately, Safari doesn't have str.normalize(). Adding
normalization capabilities to our JS side would have involved
introductiing libraries such as unorm, which is rather big.

We could have done it on the C side, but it involves introducing icu,
which is far from trivial too.

After much fussing around, I stumbled on a simple solution: URI-encode
our URI when creating our browser table row. This magically prevents
Safari from trying to mess with our unicode form before we get the
chance to send it back to our server.

Previously, browsing entities with non-ascii characters in their URI
under Safari wouldn't work. Directories would be empty, songs wouldn't
be added. I haven't tried it, but this behavior seems to be common to
Webkit-based browsers, so Chrome would be affected too.

This turned out to be because Safari normalizes all unicode strings to
NFC, breaking the link with MPD-spewed URIs, which are in NFD.

An obvious fix would have been to normalize all URIs to NFD, but
unfortunately, Safari doesn't have `str.normalize()`. Adding
normalization capabilities to our JS side would have involved
introductiing libraries such as `unorm`, which is rather big.

We could have done it on the C side, but it involves introducing `icu`,
which is far from trivial too.

After much fussing around, I stumbled on a simple solution: URI-encode
our URI when creating our browser table row. This magically prevents
Safari from trying to mess with our unicode form before we get the
chance to send it back to our server.
@ghost
Copy link
Author

ghost commented Jun 21, 2015

Now that I think about it further, normalization (the first solution I thought of) wouldn't have worked. It's improbable that MPD mangle with unicode forms at all. The NFD form probably comes directly from my filenames.

So the proper fix is to do what is necessary to avoid any form mangling at all, which is what we do in this PR.

This also make our steps to reproduce more precise:

  1. Have a dirname/filename with non-ascii characters in them, utf-8 encoded in NFD form.
  2. Add it to MPD.
  3. Browse that dirname/filename with ympd under Safari.
  4. See that browsing doesn't work.

Also, here's a link that explains what this whole NFC/NFD thing is all about: https://en.wikipedia.org/wiki/Unicode_equivalence . See the table for an illustration of the differences.

@notandy
Copy link
Owner

notandy commented Jun 24, 2015

Thanks for pointing this out

notandy added a commit that referenced this pull request Jun 24, 2015
Fix browsing for non-ascii entity URI under Safari
@notandy notandy merged commit 7b05dc1 into notandy:master Jun 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant