1496984 - Text editing in input and textarea occasionally loads previous input/next word/etc from some cache

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Keyboards and IME, defect, P2)

Description

[tnm.spam]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Steps to reproduce:

I can reproduce it with my bank's money transfer form's "amount" field always. Unfortunately it's not public page. I put in a bunch of numbers like 11111111111111 (fourteen 1s), then I delete them all using the backspace. When the field is empty I hit backspace one more time and suddenly the text box is filled again with 1s, just one less then previously, so now it's filled with 1111111111111 (thirteen 1s), if I delete it all and hit one more backspace then it is filled with twelve 1s and so on, until some kind of underlying cache is emptied and suddenly I reach the point when hitting backspace does nothing. Now I want to type in any number, like 1234 and it will first accepts and shows 1, but then the second number overwrites it and at the end the field contains 234.
As I said, this always happens with this form's field, but occasionally similar thing happens on common html textareas or facebook's comment box (mobile view) where I type in a text, I realize that I need to edit a word. During editing I don't actually edit what I see, sometimes randomly firefox inserts the original word (that I started editing) back where the cursor is. So if I started editing the word "apple" and I try to inject "etre" after l, I can end up with "appltrapplee" or something similar.

I tried the bank form's field in chrome for android, duckduckgo browser and even firefox focus and they all work fine. Firefox desktop also works correctly. I tried different keyboard app with the same results. I tried disabling all add-ons and disabling form filling in about:config, but those steps did not help either. Issue is the same in current Firefox for android beta and nightly. (And I had this issue for a long time on multiple phone, this is just the first time I was able to find a scenario, where I could reproduce it always)

The bank form's input field has the following source (I'm not sure it helps, but maybe):

<input defwidth="" style="text-align:right;width:130px;;" callback="" picformat="@R@O||| ||| ||| |||,||" class="etkinput_noerror" value="" id="Amt" name="Amt" onchange="" onkeyup="" onkeydown="" type="text">


Actual results:

Textarea, input is filled with garbage text from some cache.


Expected results:

User should always edit what they see, only those characters should be entered that were actually pushed by the user.

Comment 1

[tnm.spam]

Since the bank's page requires active contract to the bank, I'm willing to try "test versions" of firefox or send some debug data if instructed.

Comment 2

[Bogdan Surd, QA [:bsurd, NI]]

Hello and thank you for the report,

What device and android version are you using?

If you could get a logcat that would be very helpful in trying to figure out what is actually happening there. Please NI me if you do not know how to get a logcat, or can't find how to get on on the internet.

A video with the issue reproducible is also helpful.

Comment 3

[tnm.spam]

Samsung S8 with Android 8.0.0. But I had this issue months back on my Nexus 5x as well.
I'll try to collect logcat logs and make a screencap in the following days.

Comment 4

[tnm.spam]

Actually, it turns out my bank has a demo version of it's web banking, and I can give a direct link to reproduce the issue:

https://netbank.granitbank.hu/eibpublic_granit/demo/en/mbhct.html

If you open it in Firefox on Android and put some numbers in the Amount field, enter 12345 and you'll notice that the 2 will overwrite the 1, so the result will be 2345. If you start to delete at first it will seem to be OK, but if you start again it will give a very unexpected mix of previous numbers and the current input.

If you try this in Firefox Focus, this issue is not present.

Opening the page in desktop version of Firefox, I see that it pops up suggestion box, and in rare occasions that suggestion box also contains some earlier input.

I want to emphasize that I have similar text input issues on other webpages as well, where upon entering a word into a textfield ends up being a mixture of the previous content and my current input, but this bank page is where I can safely reproduce the issue (or an issue).

Note: the page will "log the demo user out" after a few minutes of inactivity.

Please say so, if you still need the video, or if you can't reproduce the issue.

Comment 5

[Bogdan Surd, QA [:bsurd, NI]]

Thanks for the demo page, I was able to also reproduce this using it!

There is an issue when typing or erasing values in that field, having a quick look over it, seems to be a webcompat issue since chrome does not have this problem.

@Mike could you have someone look over this?

Comment 6

[Mike Taylor [:miketaylr]]

Yep, can reproduce in 62 Fennec, as well as Nightly 65.

<input defwidth="" 
       style="text-align:right;width:130px;;" 
       type="text" 
       callback="" 
       picformat="@R@O||| ||| ||| |||,||" 
       class="etkinput_noerror" 
       value="" 
       id="Amt" 
       name="Amt" 
       onchange="" 
       onkeyup="" 
       onkeydown="">

Some wacky stuff happening here. Dennis, can you take a look please?

Comment 7

[Marcia Knous [:marcia]]

Dennis - Any update on this bug? Thanks.

Comment 8

[Dennis Schubert [:denschub]]

This site is broken in multiple ways. Just for the record, even in Chrome, the site is not fully working, but the character input validation there fails completely, allowing you to enter letters etc.

The site keeps a copy of the input's value to format it and then override the value whenever something has changed. This happens mainly on the keypress event. On entering a number in Firefox, keypress gets fired and the value is updated accordingly. On hitting backspace, the site is using a keydown handler to run a "remove one character and override the value" method. However, while we do dispatch keydown events, no key/keyCode is set, so the site ignores the event. That is, until the input is empty, at which point we dispatch a keydown event with keyCode=8, which the site recognizes and re-fills the field with the previous value minus one character, explaining why previous contents suddenly appear again.

Note that our backspace behavior is completely consistent with Chrome's. The key difference here is us dispatching keypress events on inputting numbers/letters, while Chrome is not.

Masayuki, I know we have a lot of special rules for Android input events, and I don't fully understand all of them; in fact, I don't think I understand Android input at all. :) Do you know why we dispatch a keypress event here, while Chrome is not?

Comment 9

[tnm.spam]

Thanks for the deep analysis. Even if this webpage is broken, I only linked it as this (or similar) issue occurs with other (completely unrelated) pages as well.
I would also like to reiterate that Firefox Focus does not have this issue, not just Chrome.
May it be worth analizing what is different in behaviour between firefox for android and focus? I still have a feeling it is connected to saving form history, which focus obviously does not have.

Comment 10

[tnm.spam]

I meant to write: " I only linked it as this (or similar) issue occurs with other (completely unrelated) pages as well, but here the issue was always reproduce-able, while other pages only rarely broke on this."

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, our Android implementation must emulate Linux's behavior. That is, when IME inserts a committed character, using a keypress event rather than using a set of composition events. On the other hand, Chrome does not use keypress nor a set of composition events for this behavior. Instead, Chrome just dispatches beforeinput, but we've not implemented it yet. So, it's currently impossible to behave exactly same as Chrome. So, this is really same issue of bug 1520983 (but not a dup).

If we'd use a set of composition events rather than a keypress event, we can fix this bug only for the bank's app. However, I'm not sure it's safe for the other web apps. Current our behavior is compatible with our Desktop Firefox. I mean if web apps send desktop version to Firefox for Android, current behavior must work, but the "fixed" behavior may break it. (Note that I see 229 keyCode value (meaning "handled by IME") and "Unidentified" key value on Chrome even when Backspace key removes previous character on Chrome with GBoard (English). This is really odd behavior to me.)

On the other hand, when I connect Bluetooth keyboard to Android device, I see keypress events even on Chrome, but looks like the bank's form work fine. So, dispatching keypress event may not cause this bug.

(And I wonder, Safari on iOS works as similar to us or Chrome?)

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

And some notes (may not be related to this bug):

• CtrlKeyDownHandler does nothing if window.event is null or undefined. Then CtrlKeyHandler (keypress event handler) does similar things. However, we'll set it to non-null starting from 66.
• CtrlKeyHandler checks UA a lot, but we don't hit any of them.
• CtrlKeyHandler does if (event.returnValue) event.returnValue = false;. This will be same as calling event.preventDefault() starting from 66.
• CtrlKeyHandler does if (event.preventDefault) event.preventDefault = false;, but event.preventDefault is a function...
• Both CtrlKeyDownHandler and CtrlKeyHandler return false and they are set to onkeydown and onkeypress. So that they don't need to touch event.returnValue and event.preventDefault...

Anyway, on Chrome, all keydown and keyup events have 229 for keyCode. So, CtrlKeyDownHandler nor CtrlKeyUpHandler does nothing if you use GBoard and even when Backspace but there is a character to delete.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(Perhaps, even if we change our behavior, when Firefox for Android is in PC site mode, we should keep current behavior because web apps for desktop browsers may not aware of composition events.)

Comment 14

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 15

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 16

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.