01-10-2014 08:43 AM
This bug emerged with the latest software updates offered by BlackBerry devices, they show OS version 10.2.0.1791 and 10.2.0.1803. I also tested on a number of simulators, and have determined, that the bug was not present on BlackBerry 10.1.X.1483 and older.
Our app uses an EditText object to gather user input. Sometimes we change the content of our EditText programatically while editing, but in BlackBerry android runtime the keyboard seems to remember the content of our EditText and returns the whole lot the next time a character is typed.
The same code was tested on a number of Android Proper devices, and it is not present on any Android device. We also tested on older simulators, and it was not present there.
Has anybody seen this bug? Any workarounds?
Solved! Go to Solution.
01-10-2014 11:47 AM - edited 01-10-2014 11:55 AM
After a lot of testing, we have determined, that while in Android proper, content change events in EditText fields are text appends (e.g. if an EditText view has content asdf and user presses the 'g' key, the system appends the 'g' character to the EditText), in BlackBerry's Android runtime, text changes in EditText are replaces of total content with new content (e.g. if an EditText field has content asdf and user presses the 'g' key, the system replaces the 'asdf' string with 'asdfg').
This would be OK, if the system detected and honoured programmatical changes of EditText content in the application, but in the case of Android runtime it doesn't. Our user types something in the EditText and the app programatically changes it to something else, so when the user continues typing, we get everything the user has ever typed in that Activity into our EditText.
We have a name and address input, and we use an EditText for this. We offer this EditText to the user, to input their data. So the sequence goes like this:
1. User selects the EditText field
2. User types their first name e.g. John
3. User clicks "save" button,
4. application saves the data and prompts user to type their last name
5. User selects EditText fiels
6. User types the letter 'S', but our EditText displays the string "JohnS"
7. User finishes typing their surname, EditText displays 'JohnSmith'
8. User clicks the Save button
9. Application saves the data and clears the content of the EditText
10. Application prompts user to type their address
11. Use starts typing their address
12. EditText content is changed to "JohnSmith46 Sunset drive"
We have a real problem with this.
Does anybody from the Android integration team have any advice for us? Is there a way to get the keyboard to start the typing anew?
01-10-2014 03:35 PM
I have managed to reliably and consistently reproduce this bug. Please run the code in the attachment (it is just an EditText with three buttons, clear content button, show keyboard button and hide keyboard button).
1. Start application
2. Press "show kb" button (keyboard appears)
3. Type a few characters
4. Press "hide kb" button (keyboard disappears)
5. press "show kb" button (keyboard reappears)
6. type a key
Expected outcome: The pressed key is added to the content of the EditText
Observed outcome: Everything that has been typed so far plus the pressed character is added to the content of the EditText.
So, for example, if you type "abc" then hide keyboard and show keyboard and press 'd', the content of EditText is not "abcd", but "abcabcd". The bug manifests itself reliably in the attached code.
01-11-2014 11:07 AM
We found a workaround. If your EditText is configured with
then the keyboard is not going to have the typing prediction feature turned on, and the bug will not manifest itself. The bug is in the typing prediction, and has been present ever since the typing prediction was turned on in Android Runtime.
03-10-2014 09:25 AM
any comments on this issue? As far as I can see it's a system issue, it might be a good idea to look into it.
03-14-2014 02:02 PM
We've made plenty of input fixes in 10.2.1. There were certainly issues in 10.2.0, as you've noticed.
Have you tried 10.2.1?
04-04-2014 05:11 AM
I can now confirm, that the bug is not present in 10.2.1, I have tested on devices with with and without hardware keyboard.