I've just been given a requirement to prevent browsers from saving data entered into specific form fields. It's been years since I've done web dev, and this is a relatively new capability. I was able to find the form field property autocomplete="off", but I can't seem to find any documentation indicating which browsers support it. Can anyone point me in the right direction of a chart of form attributes and browser compatibility?
Be aware that all major browsers are moving towards ignoring the attribute for password fields.
I can only offer anecdotal evidence, but I've yet to come across a browser that fails to respect autocomplete="off", this experience covers:
Firefox 1.5+ (Windows and Ubuntu)
Opera 6+ (Windows and Ubuntu)
Chrome v2+ (Windows and Ubuntu)
Epiphany 0.8 (ish) (Ubuntu)
Midori (I can't remember which version)
Safari v1+ (Windows)
IE 4 - 8, Windows.
I'm aware that Greasemonkey scripts, and presumably other user-scripts, can disable the autocomplete setting.
There's a couple of articles I found that might be useful to you:
How to turn off form auto-completion
Using auto-complete in html forms
Password managers now ignore the autocomplete attribute for password fields in the major browsers as of:
IE11
Firefox 30
Chrome 34
Safari seems to have an opt-in option to ignore them
It should still work fine for disabling autocomplete on form fields, but no longer affects the password manager.
As of Chrome v34, autocomplete="off" is now ignored by default.
This somewhat debatable feature can be disabled in the flags configuration by visiting chrome://flags
http://news.softpedia.com/news/Chrome-34-Seeks-to-Save-All-Your-Passwords-436693.shtml
If you're able to use JavaScript and jQuery, you can place this on load of the html:
$('#theform input').val('');
Except for Maxthon Browser I think, they are famous in china and making a name now worldwide. They don't treat Autotocomplete=off power very well. It won't work with them.
Some solution is not working in modern browsers.
Another solution link is given here. which works in all modern browsers.
Input type=password, don't let browser remember the password
You can use autocomplete="off" in this given soluton
Matter of fact, both username and password fields doesn't react to AutoComplete=off in all the latest browsers.
td;dr: To check on compatibility across browsers, here is an official MDN doc on turning off autocompletion with the link for compatibility - https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion
A little longer answer: Your issue is because of Chrome's autofill feature, and here is Chrome's stance on it in this bug link - https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164
To put it simply, there are two cases -
[CASE 1]: Your input type is something other than password. In this case, the solution is simple, and has three steps.
Add name attribute to input
name should not start with a value like email or username, otherwise Chrome still ends up showing the dropdown. For example, name="emailToDelete" shows the dropdown, but name="to-delete-email" doesn't. Same applies for autocomplete attribute.
Add autocomplete attribute, and add a value which is meaningful for you, like new-field-name
It will look like this, and you won't see the autofill (and the value you enter won't be cached) for this input again for the rest of your life -
<input type="text/number/something-other-than-password" name="x-field-1" autocomplete="new-field-1" />
[CASE 2]: input type is password
Well, in this case, irrespective of your trials, Chrome will show you the dropdown to manage passwords / use an already existing password and show the prompt to update the cached password. Firefox will also do something similar, and same will be the case with all other major browsers. Have a look at the MDN doc link I shared at the very top.
In this case, if you really want to stop the user from seeing the dropdown to manage passwords or the prompt to save the credentials, you will have to play around with JS to switch input type, as mentioned in the other related questions.
Related
TL;DR
How/why are some browsers able to search and highlight text in the HTML body which is followed by #:~:text= in the URL?
Explanation
One day I was searching for something on Google, which lead me to Quora's result. I observed that 2 sentences were highlighted in yellow, which were part of URL after the aforementioned parameter. I thought this would be Quora's feature for SEO or something, however, also found this on Linkedin, and Medium, and so on.
I'd like to know:
What is this highlighting called? Why/how does it work?
This seems to be browser-specific. What kind of browsers support this?
It seems to work on Chrome and Edge; but not on Firefox, Safari, and IE.
Does a frontend programmer need to incorporate something in the code to have search engines highlight content on their web-pages? (Based on the assumption that search engines actually appends the relevant string predicted by user's query)
The highlighting is called Text Fragments. Its a new feature that was recently added to Chrome 80. It works by specifying a text snippet in the URL hash.
Yes it is browser specific.
No, the experience that you get when clicking on a link from Google's search results is part of Featured Snippets which are algorithmically determined. There is nothing you can incorporate into your code to prompt search engines to highlight text on your page.
There is no markup needed by webmasters. This happens automatically,
using Scroll To Text for HTML pages
https://chromestatus.com/feature/4733392803332096. See also more
background here: https://support.google.com/webmasters/answer/6229325
Sources:
https://web.dev/text-fragments/
https://www.theverge.com/2020/6/4/21280115/google-search-engine-yellow-highlight-featured-snippet-anchor-text
https://www.theverge.com/2020/6/18/21295300/google-link-to-text-fragment-chrome-extension-chromium-highlight-scroll-down
https://searchengineland.com/google-launches-featured-snippet-to-web-page-content-highlight-feature-335511
https://blog.chromium.org/2019/12/chrome-80-content-indexing-es-modules.html
While text fragments is natively implemented only in latest Google Chrome (and the latest versions of Chromium-based browsers, such as the new Microsoft Edge), there is a browser extension/add-on that seems to enable it on Firefox and Safari: https://github.com/GoogleChromeLabs/link-to-text-fragment
It appears to use #ref-for-fragment-directive:~:text= and additional arguments (instead of just simple #:~:text=).
Firefox: https://addons.mozilla.org/firefox/addon/link-to-text-fragment/
Safari: https://apps.apple.com/app/link-to-text-fragment/id1532224396
Curiously enough, the extension has also been made available for Chrome and Edge too (!).
.
UPDATE: I'm testing it on Firefox Developer Edition, and it doesn't work for me.
I upgraded to Windows 10 whenever MS offered the free update. I have the autocorrect features turned on in the Typing config section as recommended.
However, even though this is on, this does nothing in IE 11 even though it is mentioned it will in this article on Microsoft Answers (says see Section D).
Is there a trick to get this working? Is there some HTML 5 attribute that also needs to be included for this to work in IE 11 (can't use edge). Spell check works in Chrome and Firefox (only via right-click menu option), so it seems it's an IE 11 issue?
have you tried the spellcheck attribute: https://www.w3schools.com/tags/att_global_spellcheck.asp
<input spellcheck="true">
Some change in recent Chrome versions (likely in June 2017) cause options in a <select> input to render much bigger than in other browsers (or in older versions of Chrome).
For example, dropdown on this w3schools page on some machines renders like this (Chrome 60.0.3112.90, 64 bit, Windows 10):
instead of expected (Firefox 55.0, 64-bit, Windows 10):
Is there any workaround that can be implemented in code to prevent it from happening (CSS solution preferred)?
So far I've found:
Discussion on Chrome product forums, which confirms that this is observed by many people, but there's no answer whether it was intentional or not. Also, observations were made that presence of touchscreen drivers in a system might cause this behaviour.
Chromium bug #739196 describing this issue, but also with no clear answer whether it's intentional or a Chromium bug
few answers suggesting that padding for <option>'s in a <select> can't be controlled via CSS by design, so this padding was never easy or possible to change.
Should be able to just add some CSS styling for the <option> tag to get it to look the way you want on most browsers.
http://jsfiddle.net/Ahreu/50/
The additional padding was added in Chrome 59 for any device that Chrome thinks has a touch interface. There currently is no way to disable this "feature".
Chrome shows two rows in Dropdown-menu
Google Chrome Help Forum
Observed same issue on Windows 10 + Chrome, with no actual touchscreen interface.
Uninstalling/installing "Synaptics Pointing Device" (touch pad on laptop) fixed the issue for me. As the other forums mentioned, it appears to be related to Chrome thinking it is on a touch enabled device. Worth a try to disable/re-install devices that may appear as such.
I am a newbie when it comes to the web development. I am creating a form and in the input tag I added the required attribute. It works on every browser except for safari5. After doing some research I found that the required attribute is not supported by Safari 5. Any suggestions as to what I should do?
As you can see here, form validation isn't fully supported in Safari, IE9 and earlier, and some mobile browsers. You will need to look into a fallback solution for those situations. These fallbacks are typically called polyfills.
HTML5 Please has some recommended polyfills for form validation: http://html5please.com/#form%20validation
One final thing to remember, even if you do client side validation, always do server side validation as well because you should never blindly trust data coming from the user.
I'm working on a mature ASP.NET/C# application (it's about three years old). For various reasons I've recently begun using the beta IE 11. However, when I first fired up the app in the browser, I noticed that it asked me if I wanted Internet Explorer to remember the password for this site. This doesn't happen in any other browser the app supports, or other versions of IE, due to the presence of autocomplete="off" e.g.
<form id="form1" runat="server" autocomplete="off">
Is this skunked in IE 11 (which I know is only beta, but I'm a bit worried about it)?
Yes, IE11 deliberately ignores this attribute on password fields (demo in the 3rd section of this page http://enhanceie.com/test/password/passwordautocomplete.asp).
Password managers encourage strong, unique password creation per site. Unique, strong passwords are difficult to remember and type on touch devices for each site, so users rely on their password manager. IE11 still honors the autocomplete=off attribute on all other AutoComplete input elements (e.g. name, address, credit cards, usernames, phone, etc).
These old blog posts might set some context: https://blogs.msdn.microsoft.com/ieinternals/2009/09/10/why-wont-ie-remember-my-login-info/
http://blogs.msdn.com/b/ieinternals/archive/2009/06/03/slowing-down-disabling-accelerators.aspx
Summarized: When the browser doesn't offer to autocomplete a password, the user assumes that the browser is broken. They then either use another browser which ignores the attribute, or install a password manager plugin that ignores the attribute.
Note: In addition to disabling autocomplete=off, IE11 will also "autofill" the password if certain conditions are met-- see http://msdn.microsoft.com/en-us/library/ie/dn629640(v=vs.85).aspx for details.