1

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.

TRT 1968
  • 472
  • 4
  • 10
  • `value="" spellcheck="false" autocomplete="off" autocorrect="off" autocapitalize="off" disabled` Then remove `disabled` attribute after the page has been loaded. – Teemu Jun 01 '20 at 09:49
  • @Teemu I assume that will require Javascript to remove the disabled?. – Keith Jun 01 '20 at 09:55
  • Not tried this, but one idea. Could you not make sure your input names are not username / password based.. eg. ``, and for your labels use an image that says `username`, this way hopefully you will have nothing that hints to Safaris aggressive auto complete that it's a username field. etc – Keith Jun 01 '20 at 09:58
  • Changing the label does cause the "on load autofocus for form filling" feature to skip that field... it now loads with the eMail field auto focussed instead. – TRT 1968 Jun 01 '20 at 11:48

2 Answers2

0

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.

TRT 1968
  • 472
  • 4
  • 10
0

You can disable the username autocomplete/autofocus behaviour by setting autocomplete="new-password" on the password input.

Lief
  • 535
  • 3
  • 5
  • 14