Last modified: 2013-10-09 14:45:31 UTC
Right now jQuery.IME is horrendously, horribly broken when using VisualEditor (a quick perusal of bugs that make it unusable include bug 54421, bug 53700, bug 53701, bug 53705, bug 53706, bug 53711, bug 54283, bug 54331, bug 54334 and others). Having the jQuery.IME icon show up when it is actively broken makes a promise to the user that we can't possibly hope to meet right now. Please disable jquery.IME from VisualEditor surfaces entirely until we can get some proper testing and work done.
Not sure I like the framing. VE mangles IME input horribly and horrendously, not the other way around may be more accurate. We can disable jQuery.IME in content editable divs of VisualEditor because it cannot handle input methods. Which class identifies editable divs of VisualEditor?
Just to be clear, VE and jQuery.IME are making incompatible assumptions about the javascript event sequences expected when entering text in an IME. To be fair, that's not really anyone's fault because (a) de jure, the standards are still emerging, and (b) de facto, every single browser/OS/IME combination seems to generate a different weird and wonderful sequence of events. We're currently refactoring the VE CE Surface code to make as few assumptions as possible about IME events. I expect we can do work from the jQuery.IME side too, to bring the two into line.
Change 88727 had a related patch set uploaded by Santhosh: Disable jquery.ime for VE till IME support is improved https://gerrit.wikimedia.org/r/88727
Change 88727 merged by jenkins-bot: Disable jquery.ime for VE till IME support is improved https://gerrit.wikimedia.org/r/88727
Patch merged. I think you can deploy HEAD of master of ULS whenever it's convenient for you guys, James. There have been no functional changes but this one in the past week.
(In reply to comment #5) > Patch merged. I think you can deploy HEAD of master of ULS whenever it's > convenient for you guys, James. There have been no functional changes but > this one in the past week. Thank you, Siebrand and Santhosh. We will probably just ride the train on Thursday rather than introduce an out-of-sequence deployment if that's OK.
> We will probably just ride the train on > Thursday rather than introduce an out-of-sequence deployment if that's OK. Preferred.
