Page MenuHomePhabricator

VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input
Closed, ResolvedPublic


Since approx. August 30-31 VisualEditor breaks when Polish-language diacritics (ążśźęćń󳥯ŚŹĘĆŃÓŁ) are input. The characters themselves disappear and text around them gets mangled and moved around.

They're all input using AltGr (right Alt) + diacritic-less version of the characters, with the exception of "x" mapping to "ź" (so, respectively, azsxecnol).

I have been unable to replicate the issue myself, but it's definitely happening.

pl.wp thread:

This is repeatedly breaking page text on the Polish Wikipedia, so I'm marking the bug "highest critical".

Version: unspecified
Severity: critical
See Also:



Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.
bzimport set Reference to bz53747.
matmarex created this task.Sep 4 2013, 12:09 PM

Examples of edits apparently exhibiting this issue:

Results of a user trying to type in "Pójdź, kińże tę chmurność w głąb flaszy!" when reproducing this bug:

Actually, I sort of have reproduced it now. I used Opera 12, but some users at pl.wp reported it happening on Chrome – it's probably not browser-dependent.

You'll probably need to set your system keyboard to "Polish (programmer's)" or similarly named one. (It's the same as standard US layout, but includes the AltGr diacritics. A "Polish (typist's)" layout exists on some systems, but nobody ever uses it, so forget it.)

Try inputting some text with diacritics, such as the "Pójdź, kińże tę chmurność w głąb flaszy!" sentence above (copying and pasting text with diacritics doesn't cause issues, you need to type it). (Strings of one character such as "ąąąą" tend to work correctly for some reason.)

Depending on your luck, it might look okay, or you might get parts of the sentence duplicated in the next paragraph. Regardless of that, try backspacing a little now. The cursor will likely be moved to someplace in the next paragraph and unrelated characters will be removed.

Try previewing the changes. The text will differ from the one shown in editing view. is a pretty good explanation, and makes clear it's not browser (or OS) dependent.

Bug 53680 shows this also happens on en.wp and fr.wp and is independent of keyboard layout.

I've tested this on master in Firefox under Ubuntu -- I managed to replicate the behavior not just in polish, but also Spanish diacritics but only when these are "added on". Trying to add diacritic to an existing character produced a pawn and then some odd duplication of characters.

That did not happen when I typed in either Hebrew or Arabic in master.

Another thing I found is that there seems to be a difference between an already-combined diacritic (like ñ which is native to the Spanish keyboard) and an "added" diacritic. When I typed the native ñ nothing broke, it added it properly and the behavior was correct.

And finally, the typing broke and the pawn appeared only when I tried to add diacritic to a latin letter.

When I tried to add "niqqud" to Hebrew letters, though, like pressing ש and left-Alt+a to produce שְ the behavior was as expected (no pawn, no problem)

Is there any progress on this? Because today's the point when I'd suggest reverting the deployment to last known good version if nobody is going to fix this.

dchan added a comment.Sep 9 2013, 4:53 PM

I'm optimistic that the following patch will fix this bug:

If someone can test this hypothesis, great; if not, then I will hopefully be able to do so later today.

Ok, the patch is merged, and due to go live on by 13 September 2013:

Please let us know whether it fixes the bug!

Marking this as "FIXED" on the expectation that it's fixed - please re-open if you find that it is still occurring.

It seems like it does actually fix the issue (for me at least). Thanks.

So that means editing will have been completely broken for only three weeks straight by the time this gets deployed :/