"speech to text" input on Android: just recently started to be completely unusable as an input method. Typing is also broken...

[taigit]

Describe the bug or issue here…

The bug is very obvious for my phone: if you edit text that was created using "speech to text" input, then your first keystroke inside that text will start destroying the current text...

In fact, if you just type and start editing that text, it also gets destroyed. ie: basic editor functionality is broken...
Basically, the editor is not working any more.

The text corruption seems to happen for text that was created during the current editing instance.
For example, if I have a blank form and create text, then editing any of that text will have problems.
But if I edit an existing chunk of text, then I can successfully insert text into that chunk. But for the newly added text, the process of editing it will cause corruption.

This problem only started to happen for me a few days ago. Before that, there were no problems. My code and the trix library code did not trigger the problem -- they have been unchanged for more than a month. So, my guess is that it was a browser update that triggered the problem.

Note: on my laptop, there are no problems. It's only on my phone that I have problems (and the code is the same for phone and laptop).

Steps to Reproduce

1. Use the native Android microphone icon, speak some English, and have Android convert it to text.
2. Place your cursor in the text that was created. Hit space bar. Watch your text being manipulated in unexpected ways.

Details

• Trix version: 0.11.2
• Browser name and version: Android chrome. 65.0.3325.109
• Operating system: Android

Note: I'm using an old Android phone: Nexus 5
but I would expect trix to work on almost all phones.

Trix 0.11.1 has the same problem. I upgraded to see if 0.11.2 fixes the problem and it does not.

[javan]

Thanks for the report! We tried to fix this with #487, which was released in 0.11.2. Are you able to reproduce on https://trix-editor.org? If so, please let me know what version of Android you’re running what keyboard you’re using.

[taigit]

Yes, reproducable on https://trix-editor.org by doing:
Add a few newline chars inside "Ruby on Rails" and it starts to go haywire.

Generally, when inserting chars there, the first inserted character seems to work, but the second inserted character will cause unexpected behavior (errors happen whether or not it's adjacent to the first character).

I'm running Android 6.0.1
Android Security patch level: Oct 5, 2016

Keyboard: stock keyboard.

It's good to hear you guys were being pro-active about the browser upgrade.
Is the trix editor working properly on some phones that are running Chrome 65? So it's only a subset of the phones that have this problem?

[javan]

Can you elaborate on "starts to go haywire"? Is it only an issue after pressing return? I'm seeing one issue where the cursor position is incorrect in the first typed word after pressing return.

@asianmack, @lateplate, @jayohms can you please test on a similar device and Android version? Do you see anything worse or different than my gif?

[taigit]

This is quite strange.
I'm not sure why, but, trix-editor.org is better behaved than before, but it still has "crazy" behavior for basic editing function.
My browser version has not changed.
Even for my own code that uses Trix 0.11.2, the editing is "less crazy".

Now, it's a little more difficult to find "crazy" behavior but here are some:

• change Ruby "on" Rails to "in". move cursor to end of word "experience.". the cursor will automatically jump back to "in".

• put your cursor between ub in Ruby, now hit 5 spaces. I get this:

Trix is an open-source project from Basecamp, the creators of Ru by ofons of people trust their text to Basecamp, and we built Trix to give them the best possible editing experience

The bug starts to appear on the 2nd space.
Similar crazyness if you use newline.
If the cursor is at the end of the word Ruby, and spaces are added then there is no problem.

• spaces inside a word: it depends on the word. try 2 spaces inside the word "basecamp" (the word, not the link) to separate base and camp. I get:

Trix is an open-source project from Basecamp, the creators of Ruby on Rails. Millions of people trust their text to Base camp campd we built Trix to give them the best possible editing experience

Similar: cursor after poss in possible. has similar problems.
But, put your cursor after the r in experience. add spaces. it works fine.

Now that the editor is more usable, I can try using it for my own work and see if i find other types of crazyness for Trix 0.11.2. I'll add them here if i find them.

[taigit]

A common and bothersome use case where the "crazy behavior" occurs: adding text to the beginning of an existing text field.

In the case where the editor starts to edit a field that has existing text:
If you put the cursor before the first character to add text at the beginning, then you have the crazy behavior.

example: add 2 spaces at the beginning of https://trix-editor.org yields this:

Trix Trixx is an open-source project from Basecamp, the creators of Ruby on Rails. Millions of people trust their text to Basecamp, and we built Trix to give them the best possible editing experience.
(note: it also turns the entire paragraph to bold)

Another thing i noticed:
After doing the "crazy behavior" with the 2 spaces added described above, if I long press to select a word (eg: Millions) then the select will fail to select the word. Instead, the cursor will move to the word "Trixx" and be placed between the 2 x's.

Trying to find a workaround for this use case (because otherwise I can't add text to the beginning of an existing form field...!).

• If I add 1 space then try to backspace it: the cursor will move to the end of the first word and delete the last character of the first word

• This workaround seems to work: I add 1 space, touch to move cursor back to the start of the document (what actually happens is the cursor will jump to the end of the first word), then I touch to move the cursor to the start of the document again. Now I can add text to the beginning of the document.

[taigit]

Just want to find out if the behaviors I described are reproducible at your end.

Also, do you have any idea about the scope of these problems: are there a large number of other phones experiencing the same problem?

[taigit]

#496 could be another instantiation of this problem because the cursor is moving to where it should not be. But that bug is on Linux (not a phone).

I tried the #496 example on:

• Windows 8.1, Chrome Version 65.0.3325.181 (Official Build) (64-bit)
• Android chrome. 65.0.3325.109

and in both cases I do not experience the bug.
So, the Trix code needs to account for variations in platform and Chrome versions...

[taigit]

#469 also produces "corruption of existing text" behavior when used on Android.

Steps to reproduce:

• use Android phone chrome. 65.0.3325.109
• go to: https://codepen.io/ncnlinh/pen/dJWRZa
• in the editor: add 8 'a' characters: aaaaaaaa
• put cursor in the middle of the previous 'word'
• type "enter" key 2 or 3 times.
• See corruption of text

Note: if you do the same actions above on Windows 8.1, Chrome Version 65.0.3325.181 (Official Build) (64-bit), then the result is different:
The "enter" key strokes don't change the text at all.
ie: There is no new line character inserted. There is no text corruption. There is simply no change to the editor contents even though key strokes were inputed.

[stale]

This issue has been automatically marked as stale after 90 days of inactivity. It will be closed if no further activity occurs.

[taigit]

The problems reported in this issue are still present, so the issue should not be closed.

[pboling]

Stale bot closing dozens of issues on this repo adds noise, obfuscates reality, and makes the project appear healthier than it is.

What more do they want? Why should people go to great lengths to document issues only to have them met with silence and eventual closure. Making a conscious decision to "not implement"/"will not fix" is one thing, but closing like this is off putting. Even if the project is mothballed, there is no utility in closing issues like this, or pull requests like this.

Perhaps the close bot would be more reasonable if the time were extended further, and if it checked that the last comment was from a Trix team member and somehow tagged as asking for feedback which never came?

Bugs and Inbox Zero are not compatible concepts. Bugs don't give a shit what the issue count is. They'll still eat your liver.