Important Keyboard Events:
Sequence of events: KeyDown-> keypress->keyup
when the input method is open:
KeyPress
The most extraordinary of these three events is that, if cleverly applied, it would be easier:
1. First of all, for most function keys there is no KeyPress event
Caps Lock, Shift,alt,ctrl,num lock 、、、 Fortunately, enter owns this event
2. For letters, numbers, the KeyCode returned by the press is unreliable
ASCII code is returned under IE and WebKit
Firfox return 0 Forever
But for KeyUp KeyDown event key values are completely unified
3. KeyPress can only capture a single character
KeyDown and KeyUp can capture key combinations. Therefore, the function of the key combination may need to be bound to the down-up event
For the Chinese input method to open the browser on the event of different corresponding and the solution:
In the Chinese input method to open the state:
Firefox: When you click on the letter key, it triggers something like this:
Why is it called virtual Defocus : This state does not actually trigger the defocus state, but it masks all keyboard events bound by the input boxes
IE, WebKit : But when the user clicks on the letter key, something like this happens.
Inspiration: Because in this state is able to capture Keyup,keydown to capture KeyCode, the front-end can be simulated keycode into the input box to achieve the input method and the input box synchronization state, and trigger in the input state when the synchronization suggestion.
So how to avoid, when the input method is running, the user is hitting the ENTER key, triggering the return key original event?
Look at the above two graphs, so it is very simple-------KeyPress event binding The original event, such as triggering a search
KeyUp binding in the Input method runtime, carriage return, space and so on need to trigger events, can also be used to detect the exit search box
So how to detect the user after the point of input?
By matching the KeyUp event that is identified in the previous question, if you need to screen the event when the IME appears, you can only bind to the KeyPress event.
Summary of the suggestion:
Starting from the beginning:
In the development of suggestion, the biggest obstacle is to check the behavior of the user, and these user behavior mainly converge on the small input box, the clever use of keyboard events, can reduce the amount of code, improve performance, optimize the user experience to the greatest extent.
The main user behaviors are summarized as follows:
1. Change the input (add, delete, paste)----------------the most important thing is continuous input
2. Keystroke function key--The main key value is:
Keycode:13--Enter
Keycode:27--esc Key
keycode:38--on the key-->webkit core will automatically locate to the first, remember to Preventdefault Oh ~
KEYCODE:40--down arrow
Development also encountered a number of small problems, and detours:
First of all, from a mental summary:
1. The wrong idea:
One: Send a request every time a user knocks on the keyboard
This is undoubtedly a simple way, but the need for a large number of Ajax, and most of them do not show the opportunity, good front-end code, should fully consider the front and back end of the interaction between the virtual consumption, the greatest degree to reduce the virtual consumption.
Second: Check the contents of the input box every time:
Every once in a while to execute the code, wasting performance does not have to say anything, the most important thing is that this mechanism can not be very good control of user input events and JS detection sequence,
When the test is complete, an error occurs after the user has entered. Although it can be used to detect the current input box state to make up, but the experience is very poor, and wasted a lot of Ajax requests.
2. After the idea of optimization:
Binding after key percussion event
The first way after the development, I found in the self-test, due to the inability to accurately monitor the user's behavior timestamp, resulting in numerous bugs, and then one by one repaired, a better idea of germination.
To determine whether to send a request, and to shield a continuous percussion event, by detecting the keystroke event of the key.
Specific ideas:
When the user focuses on the input box, start monitoring the KeyDown event, enter the state of the input box, when there are KeyDown events and input box can change-100 milliseconds after the detection of the current input box state if you do not match the previous selection can be sent back to the AJAX request
This way, according to the user input, input frequency, judge the number of Ajax requests, and through the threshold limit, reduce the AJAX request. User input more, JS detection of more, Ajax will be more, users do not move, there will be no JS detection and Ajax, the input is less slowly, a good reduction of the virtual consumption.
