Page MenuHomePhabricator

Users are redirected to percent-encoded section fragments after section editing
Closed, DeclinedPublic5 Estimated Story Points

Description

With html5 as primary $wgFragmentMode, after editing a section with non-Latin characters in its name, users get redirected to percent-encoded fragments.

  1. percent-encoded %D0 when old section is dot-encoded .D0.
  2. Expected: same encoding as TOC (HTML5 section ids).

Event Timeline

kaldari set the point value for this task to 5.Nov 1 2017, 10:45 PM

This appears to be the PHP behavior: a simple <?php header( 'Location: http://localhost/#абвг' ); redirects people to #%D0%B0%D0%B1%D0%B2%D0%B3.

We have to do this for Microsoft browsers because of their bugs. Dot-encoded sections still work for backwards compatibility.

I have a sketch of a client-side fix for this issue, however with next Chrome forcing percent-encoding on display no matter if the fragment itself is encoded or not, I have to question whether we even need a fix. Top desktop browsers:

  • Chrome: will make no difference soon, it will always diplay percent-encoded fragments
  • IE and Edge: too buggy, always get redirected to legacy dot-encoded fragments to avoid mojibake
  • Firefox: always displays Unicode

On mobile, Safari also comes into play. but it handles percent-encoding well.

COnsidering it all, is it even worth trying to fix this one if the fix will not actually make any difference?

Yeah, focusing on the top, now that makes no sense. Then now the percent-encoded well, because at least the firefox converts them (point-encoded it leaves encoded).

there are going to fix https://bugs.chromium.org/p/chromium/issues/detail?id=789163

Nothing we can do about PHP's behavior while Chrome will soon handle percent encoded fragments properly, which combined with Firefox already doing that means that we're covered for most of our supported browsers anyway.