We Keep Coding

How can one stop Safari from focussing on form fields labelled Username or Password when document loads?

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.

Populate state with values from autocomplete (react)

I have a component with inputfields and a button which is disabled unless the correct values are entered in the inputfields. This works fine but when chrome autocompletes those values on page load, the state isn't changed and thus the button stays disabled. If you click inside the form or change a value the state changes correctly.
How can I get the value from autocomplete when the component load? Autocomplete doesn't trigger the onChange or onBlur events and autocomplete="off" doesn't work either. (also I'd prefer not to turn off autocomplete anyways)

I recently came across this problem while working on my login page. After a bit of research, I came across this issue reported on the ReactJS github. To quote the key part:
If we are able to access autofilled values once the page loads, it would become very easy to write malicious code to extract information on a form intended for phishing. Giving the user no chance to react. Probably part of the reason why autocomplete="off" is ignored by browsers.
To overcome this problem we need to:
Accept the fact that we won't (and never will) have access to autofilled values when the DOM node mounts
Embrace the security concerns which are brought up by the browsers
tl;dr - It's intentional for security reasons, and it's better to validate the inputs upon submit instead.

Accessibility in javascript form validation

This is an important issue for the blind community which I'm trying to adress. How would I tell blind visitors that the username is taken?
My current set-up is not important but for examples case, I've currently got a Jquery implementation that checks the user input against a php script over ajax, which returns a json which I then display on screen in an error field. Very basic, and beyond the scope of my issue as it is working perfectly.
But if I'm blind, I won't notice that the username Batman is already taken or can't contain spaces, and that my password requires at least 7 characters.
Alternatively, the errors are listed on the error landing page after the form is submitted without javascript- it's chunky but it works. A better more dynamic solution and suport would be optimal.

As a screen reader user I usually just fill out the entire form, submit it, and if it doesn't work I then look for error text. In order to notify a blind user about invalid data before the entire form is submitted take a look at the aria-live="assertive" option scene on the following test page, section d.
http://www.accessibleculture.org/articles/2011/02/aria-alert/
Out of all the test cases section d is the only test that worked for me under firefox 18.0.1 with Jaws 13.0. For some reason the alert option doesn't work. You could use the assertive option to notify the user that something was wrong.

Is it possible for the browser to cache Javascript/DOM changes?

I am developing a form using Javascript for styling that will be used to submit many different things. However, the majority of the time the different things will only be slightly different so it would really benefit users if when you press the Back button on the browser, the form is exactly as you left it before you submitted the form.
Note: This already works when using a normal HTML/Javascript-less form, the question I am asking is how I can retain this functionality when using Javascript to hide/replace input fields etc.
I've tried History.js and HTML5's replaceState() but nothing seems to work. Also if it helps, this will be a private website that requires the latest browser installed so don't feel hesitant to recommend solutions only available in the latest browser releases.
Many thanks!
Update #1: Here's an image better explaining what I need.
Update #2: Okay I managed to crack it perfectly, cross-browser included. I'll post a solution tomorrow after I've had some sleep.

Okay so I went back to the drawing board and tried to figure something out using the tools I already know exist. The case with each browser (usually, haven't tested any non-major browsers) is that when you press the Back button after submitting a form, text input fields are usually populated. I wanted to see if this worked the same with hidden input fields, turns out it does!
So next I set up some Javascript events to listen out for the page load.
if($.browser.mozilla)
{
$(window).on('pageshow', pageManager.init);
}
else
{
$(pageManager.init);
}
This works for Chrome, Firefox and IE9. I haven't tested any other browsers but these are the only browsers that will be used for my private site so it's good enough for me. I'm sure you can set up your own preferred solution for your needs but this is what worked best for me.
Anyway the above code means every time the page loads, pageManager.init() will run. Here's an excerpt of the code I use to check if the Back button was pressed and it's not simply just a page refresh or a first-time visit:
if($('input[name="form_submitted"]').val() != '')
{
// back button was pressed
}
As you can see, it's as simple as checking if your hidden form field contains a value. To actually guarantee a value will be set, make sure to set on submission of your form:
$('#my-form').submit(function()
{
$('input[name="form_submitted"]').val('true');
}
It really is as simple as that. This is one of the best methods I can think of for determining if the Back button of a browser was pressed. Now, to cache all the form values for the visible fields it can be as simple as using JSON.stringify() on the fields and sticking it all in one hidden field which you decode later.

AFAIK, this is generally handled manually. That is, you use hashtags or pushState (with appropriate state object) and either on hash change or on popstate you grab the hash/state, and (re)build your DOM as needed.
(note, I combined two very different scenarios into one there, sorry. if you were only using hash changes, you wouldn't likely be using pushState, as pushState doesn't trigger onhashchange according to MDN.)

Why does Firefox + My code Destroys FireFox refresh

I am soo angry right now. I lost hours and i dont know why this happens. Its a semi rant but i'll try to keep it short
My code would not work, even after refreshing it was broken
I fixed my code or so i thought because it stops working without me changing anything (you would think i am imagining this...)
I somehow decide to make a new window or tab i run my code and verifies it works.
I write more code and see everything is broken again
I write test in a new window and see my code does work
I see my code doesnt work and firebug DOES NOT HELP
I notice when i create a new tab everything works
I realize refreshing does not work and i MUST make a new tab for my code to work.
Then i knew instantly what the problem was. I modify a display:none textbox but i set the values incorrectly. I cant see it because it is hidden. Now some of you might say its my fault because when doing a refresh all of the data may be cache. But here is the kicker. I was using POST data. I posted in between of the refresh each and everytime.
Whats the point of using POST when the same data is cached and use anyways? If theres no chance for a search engine to follow a block user get link then why should i bother making anything post when security or repeat actions are not an issue? POST didnt seem to do anything.

Sounds like you're being hit by form-field-value-remembering.
When you use back and forward (but when the bfcache isn't used in browsers that have it), or in some browsers when you hit reload, the browser attempts to keep the values of each form field that were present when the page was last unloaded. This is a feature intended to allow the user to navigate and refresh forms without losing all the data they're laboriously typed into them.
So you can't rely on the value of a form field being the same at page load time as it appears it should be from the HTML source. If you have DOM state that depends on the value of a form field (such as for example a form where some of the fields are hidden or disabled depending on the value of another field), you must update that state at page load time to reflect the field values that the browser has silently dropped into place (no onchange events occur). And don't use hidden inputs to store scripting variables at all.
The exact behaviour varies across browsers. For example some browsers keep the values of hidden fields and some don't. Mozilla and WebKit put the new values in instantly as the fields are parsed into the DOM, whilst IE only does it on window.onload... and Opera, aggravatingly, does it just after window.onload, so you can only catch it by setting a 0-timeout to update state after onload. It's a nasty mess.