I have a problem with a rich text editor built around a <div ... contenteditable="true">. I've tried disabling autofill in every way that I can -- data-lpignore="true", autocomplete="off", but no matter what I try, LastPass's autofill dialog pops up on Android when I focus into the textbox, making it extremely difficult to use. I can't even dismiss it without it popping up next time I refocus the editor.
How can I make LastPass, and most likely other mobile password managers that I don't use, ignore this div with the contenteditable attribute on it?
It seems that setting the aria-label html attribute on the div fixed this in my case. That attribute alone seemed to solve my issue, even with autocomplete and data-lpignore removed.
I'm not entirely sure why it was broken in my case -- I was using the Quill editor. It may have something to do with how the editor is set up in the framework I'm using. However, this answer should be useful to anyone facing a similar issue.
It would be really great to find out the actual science behind this for a more satisfactory answer!
Related
I know there are tons of ios display problems in stackoverflow and other places online and all of their one solution is giving
web-kit-appearance: none
such as the post below
CSS submit button weird rendering on iPad/iPhone
But I happen to know that this also kills the radio buttons and checkbox in androids. It solves the ios styling problem and another problem comes up.
Does anyone know any solutions about this?
This is the iDevice overwriting your case button styles. You can make use of the !important tag to overwrite the rendered styles.
I have the following contenteditable area
<div contenteditable="true"><p><br /></p></div>
The "<p><br /></p>" is from the database. It's not I hardcarded it on HTML. So I can't change that. That's a very strange behaviour for Chrome on Android.
When I type 'ok', press enter, and then press backspace again, the text is autocorrected as 'OOk'. And the cursor is still on the second line.
You can try this with Chrome for Android: http://jsfiddle.net/73s4pjz9/
How can I solve this strange bug?
Well, you can't, sadly.
To my knowledge (and I've spent hours researching this infuriating bug), there isn't a way to fix it on your end because it's a bug with the WebView class that hasn't been fixed for about 2 years. Basically what happens is Android's autocorrect engine gets out of sync with the contenteditable's selection and things get messy.
Sadly, I wasn't able to find a solution to this bug, so your best bet is to either make Android users suck it up or give them a native textarea without the cool WYSIWYG features.
I'm currently developing an application targeted at android and desktop devices using apache cordova and HTML5.
In order to get the numeric keyboard to pop up I've used input type="number", which works fine.
However, the input field should also accept strings. The current functionality of type=number is that the ui seems to allow for strings to be entered, but the value property of the element is not changed if the input is invalid (e.g not numberic).
Is there a way of getting the numberic keyboard on mobile devices, while still being able to enter text?
My inital tries consisted of capturing the keydown event and manually setting the this.value property. I've tried this using jQuerys .val() and of course the more 'native' approach element.val += char. None of which work. UI is updated, but the change is not reflected in the model.
EDIT
For the next guy trying to achieve this.
1) The HTML solution.
As #LuudJacobs mentions in the comments below; There's currently no way to decide which keyboard is shown except for defining the type-attribute. Though some devices have a button to go back to alphabet keyboard, its not the case for every device. And can not be used reliably.
2) Writing a phonegap/cordova plugin.
It is possible to write a plugin to show and hide the keyboard at will. But, as far as I could find, there is currently no way of programmatically telling it to default to the symbols keyboard. Thus the functionality achieved is similar to using type=number and type=text in the HTML. Another problem with this approach is the diversity of keyboard for android devices, where even users themselves can install their custom keyboard. The functionality of the keyboard can are therefore unknown. What works on one device, may not work on the next.
3) JS/HTML/Canvas solution
Finally... A feasible solution. I suggest taking a look at this walkthrough as it shows an easy way to creating the keyboard using just html and js. Another option would be to use a canvas, and draw the keyboard yourself, but I would imagine that this is more error prone and harder to do.
As explained in the HTML5 spec you can not have anything but valid floats in a input type="number". So You can not. On a sidenote: how would users enter text when they'd only have a numeric keyboard?
I'm using HTML5 validation to validate a form. The validation process works but the problem is how validation messages appears in Chrome for Android.
How can I fix this? It happens every time I test.
It seems you have two problems:
The shadowdom of older webkit versions can be targeted with general selectors. I.e.: form.my-form div Try to use classes as last selector part: .my-form .my-div. Maybee you should also check wether a * {box-sizing: content-box;} needs to be addressed. Alternativley you can fix those styles, by re-adding right styles using the webkit pseudos: http://trac.webkit.org/wiki/Styling%20Form%20Controls#Formvalidationmessage and http://trac.webkit.org/wiki/Styling%20Form%20Controls#WebKitr82180orlater
I'm not sure wether this is happening, here (your picture is not clear). There is an overflow bug in older webkit versions. Do not use overflow: hidden with positioned element as a wrapper for your form fields
I have form where several inputText fields are there which are binded to a backing bean. Strange behavior is happening with last textfield which is showing value present in some other text field (random). If I make last textfield as outputText, then that value shift to the previous textField and outputText has correct value then.
Another noticable behavior is when form is getting loaded, it shows correct value but when it is loaded completely, it changes that value to wrong one (randome). Also, on cancel it shows correct value momentarily.
I hope this explanation makes some sense. Anyone else with same kind of problem? Please let me know, if there is any solution for this. Let me know, if more info is needed.
This is happening specifically on Android and chrome browser.
I've experienced some strange autocomplete bugs in Chrome as well which get triggered by very specific form/input names/labels. The Android stock browser uses the same Webkit browser engine (and Apple Safari also), so that explains why they have the same problem. Try updating the browsers. Note that this is not specifically related to JSF.
From the server side on, your best bet is to try to turn off the autocomplete feature by setting the autocomplete attribute of the input elements to off.
<h:inputText ... autocomplete="off" />