Last modified: 2014-04-03 11:35:00 UTC
Created attachment 13223 [details] Screenshot of incorrect text placement 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 Input: [ENTER/RETURN KEY]x2 (two newlines) agar[SPACE]ma Expected output: [NEWLINE]x2 (two newlines) अगर[SPACE]म Actual output: [NEWLINE]x2 (two newlines) अग[NEWLINE]र[SPACE]म Once [ENTER/RETURN KEY]x2 followed by agar[SPACE] has been pressed, Bug 53706 shows up. If one continues the input, this bug is what happens. The incorrect placement is accompanied by the following incorrect bahaviours: The VE toolbar shows no format (while the editing had been begun with paragraph) Cursor movement is incorrect. When the cursor is at the end, pressing up key takes it to the end of the first line, then pressing the down key takes it in the second line after the [SPACE] and before म It is here that the incorrect behaviour occurs. Pressing either the left or the right arrow keys takes it to the end of the line (ie after म) While this should happen on right arrow key press, the left arrow key press should take the cursor(caret) to before the space. Also, when at the end of the second line, pressing backspace does nothing. Similarly pressing delete anywhere in the second line does nothing. The second line effectively becomes irremovable, while the first line can be removed. Note: Page used for this test is [[:w:hi:सदस्य:Siddhartha Ghai/sandbox]]
This bug (or a variant of it) seems to happen when using Google input tools for hindi. Steps to reproduce: Open a blank page Edit it in VE Enable google input tools IME Type something. example keystrokes: agar[SPACE]main[SPACE]kahoon[SPACE][RETURN KEY] Expected output: The text is typed(exact output text would depend on the IME's translation memory, macros used etc.) with a newline at the end and the cursor (caret) in the newline. Actual output: The text is typed correctly, the newline is also placed, but the cursor remains in the first line. The formatting dropdown of the VE toolbar is blank. It changes back to paragraph on pressing either the right or left arrow key (haven't tested with any other key). Pressing the return key again causes the newline to disappear while the text remains (variant of Bug 53705 ?). The same behaviour (correctly) takes place on pressing the delete key. Possibly different bug: When at the end of the first line, pressing the left/right arrow keys a bunch of times and then pressing the return key made me somehow end up with ♙ as the only text and all the input text gone. Also note that this bug doesn't seem to appear when using the native windows input devanagari-INSCRIPT
This bug was also seen when VE testing revealed Bug 53711
There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013: https://gerrit.wikimedia.org/r/#/c/82858/ Please let us know whether it fixes the bug!
(In reply to comment #3) > There's code to address this bug in the following patch, which is due to go > live by mediawiki.org on 13 September 2013: > > https://gerrit.wikimedia.org/r/#/c/82858/ > > Please let us know whether it fixes the bug! The patch doesn't fix the bug. The behaviour has changed, however, and on first look it appears to be for the worse. System environment: Win 7 X64 SP1 Google Chrome 29.0.1547.66 m Input and expected output: Same as in comment 0 Test at hindi wikipedia: Test url: https://hi.wikipedia.org/wiki/%E0%A4%B8%E0%A4%A6%E0%A4%B8%E0%A5%8D%E0%A4%AF:Siddhartha_Ghai/sandbox?veaction=edit What actually happens: (is too weird to be explained without prose) 1. After inputting 2 newlines, as soon as a is pressed, VE shows input of अ but one line above the current line, i.e caret automatically moves from line 3 to line 2. 2. Further inputting gar[SPACE] makes bug 53706 to show up, ie we have अगर[SPACE] in the second line with the space and newline selected, and the formatting dropdown having blanked. 3. Then inputting m makes म् appear, but its in the next line, i.e line three. 4. The caret has also moved back to line three ahead of it. 5. Then, when the final a is input, the अगर[SPACE] in line two changes to अग with the र[SPACE] having moved to the beginning of line three followed by म . The text in line three is irremovable. Test at Mediawiki.org: Test url: https://www.mediawiki.org/wiki/User:Siddhartha_Ghai?veaction=edit Firstly the page is blanked and the formatting reset to paragraph. The input described in Comment 0 is then done. What actually happens: Step 1-5 same as hindi wikipedia. Following this, after a (noticeable) fraction of a second, the text र[SPACE]म appears in the first line and the newline between lines 1 and 2 is selected. Caret movement is weird. When caret is at the end of the text (i.e end of third line), pressing a left arrow key takes it straight to the beginning of the second line. A right arrow keypress takes the caret back to end of third line. This effectively means that the text in lines two and three is non-navigable ( bug 53711 ). Pressing a backspace at the end of the third line removes the entire second line text, taking the caret to the second line. The first line is both navigable and removable. The third line text however, is irremovable.
The behaviour has also changed for the input described in Comment 1 Test at hindi wikipedia: Test url: https://hi.wikipedia.org/wiki/%E0%A4%B8%E0%A4%A6%E0%A4%B8%E0%A5%8D%E0%A4%AF:Siddhartha_Ghai/sandbox?veaction=edit Input: agar[SPACE]main[SPACE]kahoon[SPACE][RETURN KEY] Output: Fine except the newline never appears, no matter how many times the return key is pressed. The newline does not appear even when google input tools are disabled and the keyboard switched back to English (United States). The formatting dropdown is blank. The text is non-navigable ( bug 53711 ). However, pressing the left and right arrow keys a bunch of times and then pressing the return key still causes the text to be replaced with a newline followed by ♙ Test at Mediawiki.org: Test url: https://www.mediawiki.org/wiki/User:Siddhartha_Ghai?veaction=edit The behaviour with google input tools seems to be correct with the newline being placed correctly, and the text being navigable.
Thanks for specifying the exact keystrokes -- it really helps! There's a specific input issue when the whole page is blank (whether or not an input method is used, i.e. even if you just type ASCII characters). Could you please try typing some text on the following page, under the words "Testing Area": https://www.mediawiki.org/w/index.php?title=Project:Sandbox&veaction=edit Then click "Save Page" and "Review your changes", and see whether the text appears correctly in the right-hand version. (After that, you can cancel the edit without saving). I can type देवनागरी ("devnagrI" using my Ibus Hindi phonetic IME) there, and it appears correctly.
(In reply to comment #6) > Could you please try typing some text on the following page, under the words > "Testing Area": > > https://www.mediawiki.org/w/index.php?title=Project:Sandbox&veaction=edit > System environment: same as Comment 4 Here's my primary analysis of editing on that page (without ULS). 1. In the beginning the formatting dropdown is blank. 1.1 Pressing [RETURN KEY] does not have any effect no matter how many times it is pressed. 1.2 Pressing the [TAB KEY] takes the caret to the top of the page (above the "edit this page" template) 1.3 Typing an ASCII character (or an international digit) changes the value in the formatting dropdown to paragraph. 1.3.1 If a backspace is now pressed, the formatting remains the same. 1.3.2 Pressing the [RETURN KEY] also works once an ASCII character has been input. 1.3.3 Undoing all actions takes one back to the original position and [RETURN KEY] doesn't work again. Here's what happens with ULS hi transliteration (labelled लिप्यंतरण) enabled: 1 Enabling ULS moves the caret to the top of the page (above the "edit this page" template) and the IME name लिप्यंतरण appears beside the ULS icon. 1.1 Manually taking the caret to the original location below the "Testing Area" can be done 1.1.1 If the caret is taken to the original location after the api call for the transliteration rules has completed, ULS icon shows that the transliteration method is not active (i.e no IME name visible beside the icon). This is incorrect as the dropdown for the menu shows the method selected and typing with the method works. Moving the caret manually back to the top still shows no change in the icon. 1.1.2 If the caret is taken to the original position before the api call for the transliteration rules has completed, ULS icon shows the name of the IME correctly. 1.1.3 Points 1.1.1 and 1.1.2 seem heisenbuggy and need to be confirmed. 2 In the beginning (i.e nothing typed before), typing with ULS works, but the formatting dropdown remains blank. 3 Input: agar[SPACE] Expected output: अगर[SPACE] 3.1 The output अगर appears, but the space doesn't. 3.1.1 Point to note: Per the hi transliteration rules in ULS agar itself gives अगर् i.e there is a viram ् (U+094D) at the end. ULS removes this when a space is input, i.e pressing space causes the removal of viram as well as the addition of space (this behaviour is the fix for bug 35990 ). So ULS is recognizing the space and removing the viram, but the space itself is getting lost somwehere between ULS and VE. 3.1.2 Copying the text node text from within the chrome console and pasting in an external text editor showed the text to be prefixed by U+FEFF (ZERO WIDTH NO-BREAK SPACE) 3.1.2 This text is not navigable using the left or right arrow keys. 3.1.3 The text also cannot be copied. It can be selected manually with the mouse, but copying it is not possible. Pasting the selected text in an external editor showed nothing, as if no text had been selected. Tried copying using both the Ctrl+C keyboard shortcut and the right-click menu. 3.4 Another space press is recognized. However, VE seems to treat this as the first input character. 3.4.1 The original text disappears, replaced by the space. ( bug 53705 ) 3.4.2 The formatting dropdown shows the formatting to be paragraph. To my noobish eye, it appears that if VE was told to consider the default formatting to be paragraph (i.e no blank formatting dropdown in the beginning) OR VE considered any text input without a formatting dropdown value to be paragraph, ULS input disappearing would stop (I'm guessing this since once the formatting is set to paragraph, the text doesn't seem to disappear.) NOTE 1: This bug is starting to look a lot like a catchall to me, with automatic caret movement, incorrect formatting in the dropdown, non-detection of ULS input by VE, and what not. Feel free to file separate bugs where you find them necessary (or tell me which ones need to be filed separately, I'll be glad to help). NOTE 2: I reported this bug (along with a bunch of other related bugs) editing on a blank page so as to minimize bugs interfering with each-other and to have the simplest possible steps to reproduce the problem. However, I think that some of these may be applicable even on non-blank pages. Do I need to separately test the issues for non-blank pages and report the behaviour in these bugs (or are the current reports sufficient)? NOTE 3: I'm also ending up with a bunch of js console errors from VE, but I haven't checked exactly which step causes them. I'' try to reproduce them and let you know.
Thank you very much for providing this level of detail; I can't emphasise enough how helpful it is! If you were able to test the issues for non-blank pages that would be a great help too, because it looks like the problems happen in different ways in those two cases.
Reported console errors in Bug 54331 and Bug 54334 per Comment 7 There's possibly other console error instances which need to be reported. (In reply to comment #8) > If you were able to test the issues for non-blank pages that would be a great > help too, because it looks like the problems happen in different ways in > those > two cases. Will do.
Tested out this bug for page with pre-existing devanagari text. System Environment: Same as Comment 4 Test Url: https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit Steps: 1 Enable ULS IME hindi transliteration 2 Take the 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) 3Input k 3.1 This will give the output of क् with the newline selected ( Bug 53706 ) 4 Now input g 4.1 This will give an output of ग् but this output will show up in the next line 4.1.1 This output cannot be copy-pasted into an external text editor though it can be selected in VE 4.1.2 This output is ignored in caret movement when using the arrow keys, so the caret goes straight from the beginning of the second paragraph to the end of the first paragraph just after क् jumping past ग् in between. When right arrow key is pressed the caret goes from here to the beginning of the second paragraph इस jumping past ग् 4.1.3 Pressing backspace from the beginning of the second paragraph joins the second paragraph with the first paragraph jumping past the ग् making it the last text in the page 4.1.4 Taking the caret to the end of text i.e after ग् makes the formatting dropdown go blank 4.1.5 Using the VE toolbar Undo button moves the second paragraph back to a new line but it still stays above the ग् which is still the last text on the page. 4.1.6 Undoing everything and adding a space to the end of the second paragraph and then submitting and reviewing the changes diff shows that the ग् at the end of the page is not being added 4.1.7 Typing something after the ग् shows the text added after both ग् and the second paragraph. So effectively the bug is present even while editing existing pages with devanagari text using VE+ULS.
Automatic Incorrect caret movement has been reported separately as Bug 54424
