The autocomplete module listens to keypress event for both printable keys and
non-printable keys a lot. However, we'll stop dispatching keypress event for
non-printable keys in the default event group of web content. So, autocomplete
should listen to keypress events at the system event group.
Note that it's difficult to change keypress event listeners to keydown event
listeners because if we stop keypress events at preceding keydown event in
autocomplete or satchel module, some other modules fail to handle keydown or
keypress event before autocomplete and it's not easy to investigate which
module's which keypress event listener should be changed to keydown event
listener. Therefore, this patch doesn't do it at least for now.
MozReview-Commit-ID: 7e3aklmKrXu
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
Now, callers of EventUtils.synthesizeKey() don't need to specify
KeyboardEvent.code value anymore if they assume that active keyboard layout
is US keyboard layout.
Note that this patch changes the meaning of only test_bug551434.html.
Some callers in it don't match the key value and code value but that looks
like that they don't checking such odd keyboard events. So, they must be
bug of the test.
MozReview-Commit-ID: Itxo7yZ9rkK
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
* Toggle animate=false attribute on arrow panels when toolkit.cosmeticAnimations.enabled is false
* Use preferences-service component to lookup the pref in the arrowpanel binding
* Disable this pref during tests to remove a source of instability and timing-based test failures in chrome/UI tests.
* Enable cosmeticAnimations for tests which depend on existing behavior
* Re-enable cosmeticAnimations pref for browser_ext_popup_select.js which is known to be more reliable with animations
MozReview-Commit-ID: IvA2ySPPmeJ
* Toggle animate=false attribute on arrow panels when toolkit.cosmeticAnimations.enabled is false
* Use preferences-service component to lookup the pref in the arrowpanel binding
* Disable this pref during tests to remove a source of instability and timing-based test failures in chrome/UI tests.
* Enable cosmeticAnimations for tests which depend on existing behavior
* Re-enable cosmeticAnimations pref for browser_ext_popup_select.js which is known to be more reliable with animations
MozReview-Commit-ID: IvA2ySPPmeJ
* Toggle animate=false attribute on arrow panels when toolkit.cosmeticAnimations.enabled is false
* Use preferences-service component to lookup the pref in the arrowpanel binding
* Disable this pref during tests to remove a source of instability and timing-based test failures in chrome/UI tests.
* Enable cosmeticAnimations for tests which depend on existing behavior
MozReview-Commit-ID: IvA2ySPPmeJ
* Toggle animate=false attribute on arrow panels when toolkit.cosmeticAnimations.enabled is false
* Use preferences-service component to lookup the pref in the arrowpanel binding
* Disable this pref during tests to remove a source of instability and timing-based test failures in chrome/UI tests.
* Enable cosmeticAnimations for tests which depend on existing behavior
MozReview-Commit-ID: IvA2ySPPmeJ
Running eslint with --fix didn't fix many of the issues. The majority here had to be fixed by hand but a significant majority of the issues were related to a few files that I was able to use find-and-replace with. I regret not making this in to separate commits of the hand-fixes and the fixes from --fix but I don't recall --fix fixing any of the issues.
MozReview-Commit-ID: ANyg2qfo3Qx
