We Keep Coding

Logging in to the Netflix website using JavaScript

I'm trying to write a wrapper for the Netflix web page in Qt using QWebEngine so that I can use my remote control to navigate. For those who didn't know, the Netflix website can't even be navigated using the arrow keys...
So, anyway, I have used QWebChannel to inject some JavaScript code into the web page, and can (visually, at least) modify the relevant elements:
document.getElementsByName("email")[0].value = "%1";
document.getElementsByName("password")[0].value = "%2";
document.getElementsByClassName("btn login-button btn-submit btn-small")[0].click();
This actually works (I can see the fields filled with what I provide for %1 and %2, and the button is pressed programmatically), except for one crucial issue: this results in the messages below the input forms telling me "Please enter a valid email." and "Your password must contain between 4 and 60 characters.". These tell me somehow just setting the HTML elements' values doesn't have the same effect as me manually typing in the values. Could someone help me figure out why this doesn't work, and how I can make it work? I would like to restrict myself to plain JavaScript, it seems like a simple enough task to achieve without e.g. jQuery or some other Javascript library.
I understand this is a terrible way to approach the whole Netflix-on-a-HTPC thing, but I don't want to go digging through e.g. Flix2Kodi's Python to figure out what they are doing (which seems to me is a lot more susceptible to bad breakage than the end result I'm aiming for).

The input field for the email uses some sort of HTML5 and ReactJS validation mix.
However it seems like ReactJS validation cant handle the the dynamic value change, so I tried to find a way to deactivate it, which I did not directly, but I guessed that it has to add some sort of event handler to the form so I came up with this:
var validatingForm = document.getElementsByClassName("simple-login-form")[0];
var nonValidatingForm = document.getElementsByClassName("simple-login-form")[0].cloneNode(true);
validatingForm.parentNode.replaceChild(nonValidatingForm, validatingForm);
which gets rid of all event handlers and therefore ReactJS's validation. Now you can set your value using your code:
document.getElementsByName("email")[0].value = "%1";
document.getElementsByClassName("btn login-button btn-submit btn-small")[0].click();
Note that HTML5 is still validating the inputs, so you have to provide an E-Mail Adress, if you want to get rid of that too set the input type to text before changing the value:
document.getElementsByName("email")[0].setAttribute("type", "text");
However the next page after the Button click asks for the password so you'll have to provide it there as I didn't find a way around this.
Buuuuuttt could you not have saved the password in your browser, let it do it's autofill work and fire the click event only?

What can cause Chrome saved passwords to fail?

Specifically, in a login screen with two visible inputs (a text input for the username, named 'username' and a password type field for the password, named 'password) and two hidden fields (URLs to forward successful resp. faulty requests to after validation), what can cause Chrome to fail to autofill credentials?
If I go to the login screen in Chrome, having previously saved exactly one set of username and password, it mostly autofills the fields correctly. However, every 3-15 times loading the page (apparently more often on a slow connection) it will fail to do that, leaving the fields empty. I've tried attaching events directly in the HTML to listen for change in the fields, but got nothing (literally, the events did not fire).
I use KnockoutJS, but this happens long before ko is activated, or even loaded. I use JQuery 1.7.1 and RequireJS 1.0.5. (Updating them does not seem to affect the problem.)
Are there code patterns known to have this effect? Could it be a weird bug in Chrome? Cosmic radiation?

This problem was caused by changing the action of the form with JS. If you do so, Chrome will, sometimes, decide this is not the same form at all, and refuse to autofill credentials.
It was hell finding this, so I'm answering this question myself, then maybe some poor soul somewhere can find a solution to their problem here...

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.