Some pages, like the Google login form, submit information on keydown, that
causes us to not autocomplete, because we handle keypress instead.
The patch changes autocomplete to happen on keydown.
Unfortunately formautofill also uses keydown and tries to access popup data too
late, thus it needs some hacks to work properly.
In general the formautofill code has too many indirections due to e10s, and that
makes the fix more fragile than we'd want. Ideally content autocomplete should
have its own codebase, rather than sharing the same controller as chrome code.
MozReview-Commit-ID: oAyASmDFm1
The trigger is missing a WHERE clause, and as such it ends up doing a lot more work than necessary.
The nsAutoCompleteController changes cover a bug where VK_RIGHT autofills when it's not necessary,
and by doing that it will move the caret to an unexpected position (far right) even if it didn't
actually complete some preselected text.
MozReview-Commit-ID: 1mVbxCdqVSr
When Escape key is pressed, nsAutoCompleteController needs to restore last
string which was default value of the input or typed by the user. However,
somebody may change the value, e.g., an event listener which handles
Escape key. In this case, nsAutoCompleteController shouldn't restore the
last string.
Unfortunately, when JS sets input value, DOM "input" event won't be fired.
Therefore, nsAutoCompleteController doesn't have a chance to modify
mSearchString in this case. Therefore, nsAutoCompleteController needs to
store expected input string for checking if somebody modified the input value.
For solving this issue, this patch adds a new member, mSetValue which is
modified when the input value is modified by nsAutoCompleteController itself
or mSearchString is modified.
Even with this patch, if user temporarily selects an item of the popup and
JS sets same value as the selected item from JS, nsAutoCompleteController
restores the input value with mSearchString. However, this must be rare
case and I don't have idea to fix this issue with simple patches.
MozReview-Commit-ID: lig8c7xvD7
Fixes a timing bug where in certain moments matchCount may not be in sync with the current search status,
due to previous results not being cleared immediately. Still delays tree updates to avoid UI flickering.
Fixes a theorical timing issue in unifiedComplete where a stopped search could notify a result.
Removes the no more used OnUpdateSearchResult API.
MozReview-Commit-ID: COoIN4oQT4v
Due to recent changes to tabbrowser focus behavior, now the "focus" event to the location bar
happens before the "TabSelect" event. On "focus" we would like to open the location bar popup,
but detaching the controller would immediately close it. Thus we don't want "TabSelect" to
detach the controller just to reset its internal state. Moreover, this should be cheaper.
MozReview-Commit-ID: 5NZ1TTI9NFW
Some script may have changed the value of the text field since our last keypress or after our focus handler and we don't want to search for a stale string.
