Page MenuHomePhabricator

Broken unicode character in mobile footer (ZERO WIDTH NON-JOINER)
Closed, ResolvedPublic

Description

escape('Mobile‌Desktop')
"Mobile%u200CDesktop"
encodeURIComponent('Mobile‌Desktop')
"Mobile%E2%80%8CDesktop"

Event Timeline

Krinkle created this task.Jan 9 2015, 1:28 AM
Krinkle raised the priority of this task from to Needs Triage.
Krinkle updated the task description. (Show Details)
Krinkle added a subscriber: Krinkle.

@Krinkle, I cannot reproduce this. Can you please share a URL where this happens? Thanks.

Nearly every page of every mobile page is affected in Chrome 42.

Location: https://en.m.wiktionary.org/wiki/Wiktionary:Main_Page
Browser: Google Chrome Canary 42 for Mac.

And while it should be reported upstream that this character renders as tufu in Chrome 42 and above, the character shouldn't be there in the output stream. It being visible or not is just an escalation of that issue, not the issue itself. The character is there in all browsers.

The zwnj was added to address an issue in Arabic (https://phabricator.wikimedia.org/T62916). zwnj is supposed to be a non-printing character, so it makes no sense that Chrome would render it as tofu. I guess we'll have to figure out a work-around in the meantime :(

Confirmed that the Firefox bug the zwnj fixes is still an active bug :(

Actually, it looks like there is disagreement about whether or not it is actually a bug, so it's unlikely to be changed any time soon. (See thread at http://lists.w3.org/Archives/Public/www-international/2014JanMar/0212.html)

There are two courses of action we could take:

  1. Wait and see if the tofu bug in Chrome Canary makes it to the official Chrome release.
  2. Remove the zwnj from the footer and let the Arabic wikis add it locally.

Any opinions on which we should choose?

kaldari set Security to None.Jan 15 2015, 7:35 PM
kaldari added a subscriber: Amire80.
gerritbot added a subscriber: gerritbot.

Change 185659 had a related patch set uploaded (by Amire80):
Replace zwnj in the footer with a nicer CSS solution

https://gerrit.wikimedia.org/r/185659

Patch-For-Review

See the patch. It kills the zwnj and replaces it with a CSS trick. It's still a hack, but less ugly than zwnj. It would make more sense to simply apply something like unicode-bidi: embed to the <li>, but apparently Firefox doesn't render it correctly either :(

Amire80 claimed this task.Jan 18 2015, 12:10 PM
Amire80 added a project: I18n.

BTW, it also fixes another issue that is not easily visible on a vanilla local testing instance: the "Terms of use" and "Privacy policy" links in the bottom of mobile Wikipedia pages also have this incorrect disconnection, so they need either this patch or an additional ZWNJ, which would add to the ugliness. (I only have the "Privacy policy" link on my instance.)

Jdlrobson closed this task as Resolved.Jan 20 2015, 9:46 PM
Jdlrobson added a subscriber: Jdlrobson.

Patch was merged

aude added a subscriber: aude.Apr 9 2015, 10:58 AM

we also have this issue in wikidata

http://snag.gy/7R1aQ.jpg

not sure we can / want to work around it here with css, since it is a translation.

anyway, added comment int he chromium bug ticket.