Comment 77 for bug 610915

Created attachment 8381156
patch

Summary of changes:
- add a "userTriggered" parameter to _fillForm to distinguish the onFormPassword and nsILoginManager::fillForm callers from the onUsernameInput caller
- when filling any form, if there are multiple signons that match but one's username matches case exactly, prefer it
- when filling in a form whose autocomplete was "user triggered", i.e. triggered by focus changes or a DOMAutoComplete event, don't clobber the username field value if it differs only in case (this is to handle the case where you've saved "USER:pass" but want to manually fill in "user:pass" and don't want your entered username from being clobbered when the password is filled in). This essentially undoes bug 447788, but only for the user-interaction case, not form filling on load. It might lead to confusion in the opposite direction, if the site is case-sensitive, but users manually enter the username with the wrong case (without selecting the autocomplete) and then have the password auto-filled, and then submit the form. I think that's a relatively unlikely scenario compared to the one this addresses, so the tradeoff seems acceptable.

There's a confusing twist on that last point: in the case where you explicitly select an autocomplete entry (i.e. via "Enter" or clicking the popup), nsAutoCompleteController::EnterMatch sets the input field's value before calling OnTextEntered (which fires DOMAutoComplete), so we don't hit this new case in _fillForm (usernameField.value is exactly equal to selectedLogin.username). So the behavior from that last point only really applies to focus changes (i.e. tabbing away from the field) in practice.

I copied the test, but there's so much removed, it's probably easier to just review the new file on its own. Confirmed that I added test coverage for both changes.