Autocomplete="off" on textarea fields doesn't seem to work as it does with input fields. I couldn't find anything about this on Google. Is there a difference?
Specifically, I have a page that has half normal input fields, and the other half dynimically generated via javascript. When I navigate away from the page and then navigate back, the text that was in the dynamically generated fields overwrites that which is in the normal fields. This only happens when I navigate away and then click back. If I just refresh the page, it doesn't happen. Autocomplete="false" solved this problem for input fields, but it did not for textareas.
The autocomplete attribute or property is limited to input elements, both according to Microsoft description of the feature and according to the HTML5 draft description proposed to standardize the feature. So you should expect browsers to ignore it for other elements, including textarea.
Apparently, autocomplete is not the real question, just an assumed approach, which is a wrong one. But the real problem was not really described.
Related
EDIT: this feat is impossible. since then I have given up. I shall not delete this question, but rather leave it up right here so future users can see a relevant result to their query on google regarding a similar thing
Goal: Either make a textarea bring up the virtual keyboard when focused(with js) OR make a input[type=text] have multiple lines AND bring the virtual keyboard
(I believe answered here but with unsatisfactory results.) (If anyone knows of fully compatible ways to multiple-line-ify an input[type=text] please tell me)
Expected results: virtual keyboard popup when focusing the input OR textarea fields (via javascript with no user trigger).
Real results: caret appears in text field but keyboard remains unseen.
Here's what I'm trying on a textarea:
document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent(click);
Please don't make irrelevant comments about my code organization
#WaisKamal can you show me your code since you said it works?
HTML(no CSS):
<textarea>textarea</textarea>
<input type="text" value="input" />
<script>
//document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent("click");
document.querySelector("input").focus();
document.querySelector("input").click();
</script>
You can use inputmode to determine how a virtual keyboard behaves
<textarea>textarea</textarea>
<input type="text" value="input" inputmode='text'/>
<script>
//document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent("click");
document.querySelector("input").focus();
document.querySelector("input").click();
</script>
Edit
I'm still testing this out, it seem to give some mixed results in the jsfiddle that I'm currently testing right now, sometimes it works and sometimes it does not
*Edit 2 *
It seems to have the same results without specifying the inputmode It does not work the first time the page loads but if I click somewhere on the page, it works every time I click run.
I'm only speculating here but it seems like the keyboard does not pop up without the page receiving some user interaction first, maybe this is intentional for security reasons but I didn't find any docs saying so.
As for you other question you can give a div or other container element contenteditable to have multiple rows / any dimensions you want.
-
Here is another questions and some answers to the same problem though a bit old, Show virtual keyboard on mobile phones in javascript
-
All in all it does not seem possible so show a virtual keyboard without some user interaction.
Whilst it might feel that this question should have been asked before, many times, the closest solution I can find is less than helpful, referring to 'snowflakes'. There is, however, a comment that highlights where the problem is a genuine issue.
When developing a form for a site administrator to use, any page which is set up to allow that administrator to initialise the username and password for a user seems to trigger Safari's aggressive Autocomplete / Keychain behaviour, which pulls the form's focus onto the Username field once the DOM is complete. There are some solutions to this, but they are not particularly elegant - redoing the form layout, for example, so that the Username field is the very first one or so that usernames and passwords are handled on a totally separate page / tab. To my mind that's the browser dictating the page, which is the wrong way around!
In my case, I'm pulling the form's construction details from a table of constraints so that additional fields can be added later and the form for that table amended automatically without rewriting code. This approach means that javascript based solutions are not 100% compliant with the idea of having no pages that require special measures - it's nicer to fix this at HTML or CSS level. Obviously this might not be possible; just ANYTHING that works to fix this annoying habit would be good.
I could kludge the effect I required by adding the following dummy input field right after the main body form tag:
<input type="text" id="defeatbox" style="position:absolute; top:-1000px;" autofocus />
And then changing the focus to it 300ms after DOM ready.
$(document).ready(function () {
setTimeout(function () {
$('#defeatbox').focus();
}, 300);
});
This is a REALLY kludgy way of doing it. The dummy field can't be hidden, the length of the timeout has to be determined by trial and error, and is dependent on the size of the page, and presumably the browser and the CPU speed. It also caused the first "autofocussed" box to "flash" briefly on the screen.
The more generic code:
setTimeout(function() {$('form:nth-of-type(2) *:input:first').focus();},300);
didn't work if the autofilled/autofocussed element was in that same form (mine is the second form as there's a search box on the page that's drawn first). I could autofocus the search box in the first form using this method, but couldn't pull the focus to anything 'generic' in the second form which is the one in the main body of the page.
I understand there are many questions and answers surrounding autocomplete and autofill for web browsers. I haven't seen this specific issue raised.
UPDATE: the autofill specifically happens when a partial postback executes inside an update panel
Recently, (chrome versions 70+?), Chrome has begun aggresively autofilling input fields in our webapp when a partial postback is executed. (We use asp.net web forms)
We use the partial postback to dynamically load a user control and add it to the DOM inside an update panel.
Specifically, inputs like the following simple snippet are being populated with an email:
<input type="search" class="newH4" placeholder="Search">
I've tried adding the autocomplete attribute with different values to no avail.
Here is a screenshot of the autofill:
Additionally I have other fields like entering a dollar amount which gets populated with the email as well. Is there a way to prevent this on the latest versions of chrome?
If you have a password field in your form you can add this attribute -
autocomplete="new-password"
<input type="password" placeholder="Password" autocomplete="new-password">
autocomplete="off" should be working, but in lieu of that working and given that it is not a password or email, you could feed it some random string to see if that helps
For example autocomplete="rjftgh"
Note: simply changing the autocomplete attribute to a random string, or even a special one like 'new-password' does NOT work for this issue.
Ultimately I found a solution. It is more of a hack so I'm not too satisfied with it, but it comes from Mike Nelson's answer to the following question: Disabling Chrome Autofill
His solution involves adding input elements with their display property set to 'none' above the inputs that are being autofilled. The idea is that these hidden fields absorb the autofill instead.
I did also learn a bit more about the problem with ASP.NET and Update Panels as well. When the Update Panel triggers a partial postback, it uses an AJAX library. The library contacts the server to complete the update. Whatever AJAX is doing in the background, it is also triggering chrome's autofill logic to reexecute. In other words, whenever I dynamically add a user control, the first input field in that user control's html structure was being autofilled with the user's stored email.
Again, very strange and bad behavior, but the display 'none' input fields did the trick.
If Chrome changes their autofill logic again (they will), I'll update my answer with hopefully a better solution.
I have been looking for information about this but I don't get with the solution.
I have some text fields on a page which I get updated on blur making use of jQuery events.
There's no form to submit, the update took place in the background using jQuery $.post.
If a user updates those inputs, then clicks on a link to go to another section of the page and then comes back using the browser's back button, those inputs won't show the last values set by the user but the previous ones in case there were, or empty text inputs if there weren't.
Users are reporting this as a bug (even is more a browser behavior), and I wonder if there is any solution for this.
I have been taking a look at things like this or this, but they don't solve the problem I have. I have no forms, I have no submit and I don't want to reset the form.
I've noticed this problem doesn't take place in IE 9 and either in Firefox but it does on Chrome.
The user can navigate to different pages (more than 30) with more than 12 text fields in each and therefor I have discarded the idea of storing them on sessions.
Is there any way to solve it?
Thanks.
I do not know if my solution can solve you're problem , but:
what if you bind data to you're input? e.g you can set dinamically data on input
$('input').data( 'val' , $(this).val());
and then re-bind it through
$('input').val( $(this).data() ) ;
Do not follow exactly these lines of code , I'm trying to give you an idea of what I'm wondering. I hope that it can help you.
http://api.jquery.com/data/ doc for .data()
I'm working on an online enrolment form for a training organisation. The labels for the text input boxes have been placed inside the inputs themselves using the solution at http://attardi.org/labels/
It works perfectly in Chrome, Firefox, IE9 and IE8, but for some reason in IE7 there's a problem coming up (surprise, surprise!)
If I click on the input field in the area where the label is, the browser does not focus on the input. The input field will only go live if I click on the white space after the label, or bizarrely, if I click slightly below the input field.
Is this a CSS or a JavaScript issue, and can anyone suggest a solution?
You can access the form in it's entirety at http://testing.xenongroupadmin.com/enrolment but beware - the HTML, CSS and HTML files are very hefty and could take some time to sift through!
Ditch the script you've linked to.
Use regular html5 placeholder attribute (http://davidwalsh.name/html5-placeholder) - it's the cleanest solution to get what you need in most browsers. To handle IE7/8 you can use javascript shiv, like this one: http://dipaksblogonline.blogspot.com/2012/02/html5-placeholder-in-ie7-and-ie8-fixed.html