I am experiencing a strange bug only on Samsung mobile phones that are running Androi 4+.
With Adobe AIR, every textInput is not suitable for use. The beginning of the entered word is repeated on every char input.
Here is the behaviour:
When I enter "ABC"
The input text is "AABAABAABAABAABAABC" (or sometimes known words from the dictionary)
It seems to add the whole content of the text input on each key press. Making the words repeated several times.
It also seems to be an autosuggestion (from the phone's dictionary) related bug.
The textInput is declared this way:
<s:TextInput id="tin" autoCapitalize="all" autoCorrect="false"
maxChars="19" restrict="0-9A-Za-z_\-" width="100%"
itemCreationPolicy="immediate"/>
Others devices are just running fine, even on HTC running Android 4.1, older versions or others manufacturers.
This bug has also been seen on Swype keyboards (third-party system keyboards).
Do you have a workaround to make it work?
Thanks
EDIT: The worst behaviours are caused by the restrict property. Without that, the text input is still bugged, but less. I filed those bugs at bugbase.adobe.com, please vote for it:
TextInput's restrict attribute makes user interaction totally unusable
TextInput's autoCorrect attribute has no effect
TextInput component ignores autoCapitalize, autoCorrect, and softKeyboardType properties when setting a custom skin
Regarding the mobile textInput, Adobe has really screwed us with Flex 4.6.
Set the skin class to spark.skins.mobile.TextInputSkin and you should be good to go.
Related
When I focus a text input field on Chrome on Android, the shift key is enabled ⇪, even though I set autocapitalize="none".
The input for this field is case-sensitive, so how can I help Android users to write lower-case strings by default?
Tests
Tested on Android 10, Chrome v85.0.4183.127 with Gboard.
<input autocapitalize="off"></input>
Works as expected, not capitalizing a single word.
<input autocapitalize="none"></input>
Also works as expected, not capitalizing a single word.
Suggestion
You may want to try using autocapitalize="off" (seems to be more restrictive than none in the meaning of the word, but the spec states they should be the same).
Given that this works as expected for me, it is possible that your software keyboard software is being troublesome. Try downloading and checking with Gboard and see if that resolves your issue.
I am facing same issue as this post on Android: QML TextField text erroneously capitalized on device ... All letters are capitalized for TextField control. I have mixed TextField elements where for example when I set echoNode to password, the letters are not capitalized (no issue), while fields with normal echoMode get the issue, which makes me confident its under control of either Android or Qt code.
I switched to investigate from Android side and found this post My Phone Is Capitalizing Every Word which suggests that this problem occurs only when auto-capitalization is enabled on device... I tested it, turned off auto-capitalization on device and the issue disappeared ...
After some investigation I found that most Android apps are build with auto-capitalization aware code, for example this post Why is my Button text forced to ALL CAPS on Lollipop? show solutions with Android Java code .. I wonder if this is a Qt bug or there is something to control it, for example, with QtAndroidExtras classes? while trying to avoid the use of Qt keyboard, I believe/hope there could be a solution from Qt side.
In farsi letters are attach together to form writing scripts. However when I save HTML pages using "UTF-8" or "Windows-1256" encdoings, and try to display them using webview in android, letters are diplayed seperately and in left-to-right direction (instead of RTL).
I should notice that this case is not happening in phones supporting farsi.
Correct form should be like this (snapshot from phone supporting farsi):
Bad-formed text happens in phones not supporing farsi (Persian):
It should be noticed i've used persian font in both cases.
I also see some solutions for normal Strings in java which changes character on by one in this
question
My question: Can i fix this cases (or it should be fix by phone vendors)? if possible what is solution?
I hit this bug a lot when I was doing keyboards. The problem is that the build in canvas.drawText function in Android didn't support RTL languages. There was a patch for it, but it wasn't part of the default build of Android. So only models going out to those parts of the world that used it tended to have it. Unfortunately I know of no way to test whether it has the patch. And if it doesn't, there's no way to fix it. You could try reversing the text, but then you'd break devices which did have the patch.
Long story short- there is no way to fix it. However, I'd be shocked if Google hasn't picked up the patch in mainline by now (it existed back in the 2.2 days), so its a shrinking number of phones effected.
You can try making html with reverse font sequence! just write a windows app to get font and deliver reverse one, and use it in your android device
In a web page running on an Android browser (on a Galaxy Nexus), is it possible to disable the feature that suggests words (in a box above the keyboard) and underlines them as you type?
I tried autocomplete="off" autocorrect="off", but it had no effect.
In experiencing the same issue I did some digging and discovered it is a bug in Chrome for Android. Those HTML 5 attributes are intended to do what you are looking for but are not properly supported in Chrome for Android(they do work for iOS). It appears to just recently have been fixed and hopefully should be released in an update soon.
https://code.google.com/p/chromium/issues/detail?id=303883&q=autocorrect&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified
Also feel free to Star the issue to help boost the ranking...
In a web page running on an Android browser (on a Galaxy Nexus), is it
possible to disable the feature that suggests words (in a box above
the keyboard)
No
and underlines them as you type?
No
Those are user preferences and moreover if the user bought a keyboard app, it can have its own setting to auto-complete.
So I've built a nice, shiny HTML5 application that is targeted at mobile Safari, and Android's default browser. The Android versions I'm testing it on are 2.1 and 2.2.
My app has a textarea on one of its pages, and this textarea tends to have a good amount of text in it at times. Its basically a free-form writing field.
This works as expected in iOS. However on Android, as you type, the screen scrolls wildly up and down on every keystroke, often you can't see what it is you're typing as you type, and you get dizzy from all the jumping around. Furthermore, if the content within the textarea exceeds its height, it appears to be impossible to scroll within it.
Don't even get me started on landscape mode. The above issues are even more pronounced there.
This feels like a bug with Android as there really isn't anything fancy about my textarea. I've stripped it down to the bare essentials, and it behaves the same.
Wondering if anyone else has had this much fun with their textareas on Android, and could maybe give some advice, or at least empathize?
It seems that Google has managed to mostly solve this in the Gmail web interface for Android. I'm guessing there's some JS magic going on because my markup/CSS is identical.
SOLUTION:
The 3D webkit is broken in Android, this is causing this problem. Make sure you are not using -webkit-transform: translate3d(0, 0, 0); or -webkit-backface-visibility: hidden; on anything related to the inputs. :(
If at all possible, you can lockdown the scrolling of the screen while the user is typing by setting the overflow property of body to 'hidden' - you can selectively enable/disable it on focus/blur events. Of course this does mean that your user will not be able to scroll while typing
There is no magic answer. Android keyboard input interactions with web forms is simply horrendous. You have to thread the needle very carefully to make it work properly, and keyboard behavior is not the same across Android versions. But it is possible with a LOT of work (see our Sencha Touch framework for what's possible today - the other mobile web frameworks are tackling the exact same problems too).
I experience this behavior on nearly every page. Here on StackOverflow, on a wordpress blog and many more.
I can only image that this is a usability bug/issue in the android browser and this is why I prefer native UI/application :)