Forked from T187936#3993677.
Happens on macOS High Sierra (10.13.3) in Chrome and Safari browsers.
Linux OS and Firefox browser don't seem affected.
=> Upstream: https://bugs.webkit.org/show_bug.cgi?id=6148
Forked from T187936#3993677.
Happens on macOS High Sierra (10.13.3) in Chrome and Safari browsers.
Linux OS and Firefox browser don't seem affected.
=> Upstream: https://bugs.webkit.org/show_bug.cgi?id=6148
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Dereckson | T68374 Enable Hovercards on se.wikimedia.org (Swedish chapter wiki) | |||
Resolved | Jdlrobson | T70860 [GOAL] Graduate Page Previews feature (Popups extension) out of Beta Feature | |||
Resolved | ovasileva | T154635 [EPIC] Deploy page previews to English and German Wikipedia | |||
Resolved | ovasileva | T182319 Show HTML summaries on all wikis | |||
Resolved | • bearND | T187936 List of issues of 1.3.0 summary endpoint results | |||
Open | None | T188127 Combined characters appear visually separated on macOS |
Update: the /page/summary endpoint has changed in 1.3.2 to more comprehensively flatten anchor and span elements, when possible into text nodes. I think this issue should be significantly reduced now. We might consider applying the same strategy for the reading content versions.
I'm not closing this because the issue would still exists for direct users of Parsoid, though.
The problem seems to arise when (at least) one of the characters is written as an HTML entity, eg:
&#nnnn;o
Parsoid will wrap a <span> tag around the entity in order to support roundtripping, and that span tag will "separate" the combining character from the character it should apply to, in (broken versions of) webkit.
Two possible workarounds:
My recommendation is the first, which is probably one conditional in Parsoid plus importing a (hefty) npm library containing the unicode character class database to identify combining characters.