https://bugzilla.wikimedia.org/show_bug.cgi?id=53708
--- Comment #7 from Siddhartha Ghai <siddhartha.g...@gmail.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
