Page MenuHomePhabricator

VisualEditor: Incorrect text selection with jquery.IME
Closed, ResolvedPublic8 Estimated Story Points


Screenshot of selection error

System environment:
Win 7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a blank page
Edit it in VE
Enable ULS IME hindi transliteration

[RETURN/ENTER KEY]x4 (four newlines)

Expected output:
[NEWLINE]x4 (four newlines)

no text selection should be there

Actual output:
[NEWLINE]x4 (four newlines)

the ending [SPACE] is selected with a newline. Also, the toolbar shows that VE has somehow jumped to changing the formatting to bulleted and numbered list from the original paragraph formatting.

Further, pressing a backspace deletes not only the selected space/newline, but also the typed text अगर. I think this is Bug 53705 though I may be wrong.

Version: unspecified
Severity: normal
See Also:


VE-ULS_Selection_bug.png (374×1 px, 21 KB)



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:46 AM
bzimport set Reference to bz53706.

There's code to address this bug in the following patch, which is due to go live by on 13 September 2013:

Please let us know whether it fixes the bug!

(In reply to comment #1)

There's code to address this bug in the following patch, which is due to go
live by on 13 September 2013:

Please let us know whether it fixes the bug!

The patch doesn't fix the bug.

System environment:
Win 7 X64 SP1
Google Chrome 29.0.1547.66 m

Test URL:

Enable ULS IME hi transliteration
Blank the page and reset the formatting to simple paragraph
Follow the input steps described in Comment 0

The output is the same as described in Comment 0 as far as content selection is concerned. The formatting however, instead of changing to bulleted and numbered list, has gone blank. The formatting dropdown shows no value and no button in the VE toolbar is selected.

Pressing backspace still deletes the space and the word. It also resets the formatting to paragraph.

Per the following report is for the bug behaviour when tested on a page with pre-existing text:

System Environment:
Windows7 X64 SP1
Google Chrome 29.0.1547.66 m

Test Url:

Take a caret to the end of the first paragraph using the mouse (i.e click at the end of the first paragraph to take the caret there.)
Input ag

Expected output:

Actual output:
अग् but with the newline after it selected, although the newline or space wasn't typed in this edit and existed previously.

Screenshot for comment 3


Note: Comment 3 is ofcourse with ULS IME hindi transliteration enabled.

Further testing Comment 3 seems to indicate that the newline selection happens when the last input is a consonant followed by a halant which can be input with one keystroke.

The hindi transliteration IME inputs two characters whenever an ASCII consonant is input, the equivalent hindi consonant followed by the halant character ् (U+094D)

So inputting g gives ग् i.e ग + ् , j gives ज् i.e ज + ् etc. with the newline selected.

Some hindi consonants, however, need two keystrokes to be input. So gh gives घ् i.e घ + ् and jh gives झ् i.e झ + ् etc. Output for these depends on the input speed. If one is quick, the text is input correctly with no selection. However, if one is slow, Bug 54421 shows up with the grapheme containing the duplicated text at the beginning of the article being selected.

This selection (or non-selection) behaviour takes place regardless of whether the input is one consonant or a word. The behaviour depends on what the last consonant is, one that can be input with one keystroke or one that is input with two keystrokes.

Jdforrester-WMF assigned this task to dchan.
Jdforrester-WMF set Security to None.
Jdforrester-WMF edited a custom field.

As of in UniversalLanguageSelector this should now be resolved and working for all users, and will be part of the wmf.12 release starting tomorrow.