Page MenuHomePhabricator

ZH IME input sometimes inserts latin characters
Closed, InvalidPublic

Description

From a Wikia staff member working on ZH communities:

Basically we need to type Pinyin (English words) first to select Chinese characters, but the New VisualEditors react very slowly or over fast. Before I make a Chinese word, the en words already pop up and are put in the editor.

Here's a video of the bug happening on Mediawiki.org: http://youtu.be/G1WStvYrPPA

Report comes from Mac/Chrome but it could be happening on more.

I asked if this was the same issue as T63429 but he said it was not.


Version: unspecified
Severity: normal
OS: Mac OS X 10.9
Platform: Macintosh

Details

Reference
bz72268

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:51 AM
bzimport set Reference to bz72268.
Jdforrester-WMF lowered the priority of this task from High to Medium.Jan 9 2015, 10:55 PM

This happens on zhwiki too. And well, the reporter mentioned MediaWiki.org itself! No reason to keep it in "Non-WMF sites".

Certain pinyin IMEs (e.g. MS Pinyin) like to give the latin characters in the "pinyin buffer" area ahead of time, since it helps the application (e.g. search engine) make predictions. Visual Editor sometimes randomly trips over a point and keeps prematurely engulfing these characters. The code editor for Lua and JavaScript, on the other hand, consistently displays this problem with near-zero randomness.

My personal workaround to this problem occurs is switching to RIME until I finish one edit.

Liuxinyu970226 changed the task status from Open to Stalled.Mar 28 2017, 5:04 AM
Liuxinyu970226 added a subscriber: dchan.

This happens on zhwiki too. And well, the reporter mentioned MediaWiki.org itself! No reason to keep it in "Non-WMF sites".

Certain pinyin IMEs (e.g. MS Pinyin) like to give the latin characters in the "pinyin buffer" area ahead of time, since it helps the application (e.g. search engine) make predictions. Visual Editor sometimes randomly trips over a point and keeps prematurely engulfing these characters. The code editor for Lua and JavaScript, on the other hand, consistently displays this problem with near-zero randomness.

My personal workaround to this problem occurs is switching to RIME until I finish one edit.

Thank you for your clarification, however, I doubt if you have a fixme way due to T155928#3015470:

Change 336648 (which I've just merged) makes Tab step directly into the next cell. So you still get this problem, but only once when editing multiple adjacent cells.

I think that's probably the best we can do on this, until/unless Javascript/IME integration improves. (See https://w3c.github.io/input-events/ for current activity in this area).

@Liuxinyu970226: Can you explain what/who exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on")?

Also, three years later: Does anyonw still see this problem? And if yes, can provide updated steps to reproduce? Thanks!

VulpesVulpes825 moved this task from Backlog to Closed on the Chinese-Sites board.
VulpesVulpes825 subscribed.

@Aklapper, I cannot reproduce it using the Pinyin IME on macOS 10.15.4 using Safari 13.1, Chrome 81.0.4044.138, and Firefox 76.0.1. Hence I have closed this task as invalid. If anyone can reproduce this phenomenon, please update steps to reproduce and feel free to reopen the task.

VulpesVulpes825: Thanks for the quick reply and thanks for re-testing!