I'm trying to block all input on an html text field with jQuery. The following solution works on desktop browsers:
that.input.keydown(function (e) {
e.preventDefault();
e.stopPropagation();
e.stopImmediatePropagation();
return false;
});
However, while it blocks regular input it fails to block backspace on Android (Chrome). I've also tried blocking the keyup and keypress events, but that didn't help. I don't want to set the readonly attribute, because I intend to allow the input in certain situations.
Is there any clean solution for this? Thanks in advance!
The reality is that android keyboards are not keyboards. When a text field is opened in android the text-field-owner application and the keyboard application, speaking simply, come to share a resource which is the text field contents. The keyboard app receives the entire contents of the text field and then edits - including deletions - are made locally and pushed to the app via calls like DeleteSurroundingText (for simple deletions of non-text content i.e. whitespace) or setComposingRegion/setComposingText for changes to words. This means that autocorrect can work on already-existing words.
Some android keyboards generate keypress events which reach Chrome, some do not. Sometimes it makes no sense to generate keypress events - if a word is autocorrected what keypresses should be sent?
As you are looking for the keyboard and cursor to be displayed but the field to remain uneditable until later I would suggest you implement some sort of onChange/Revert loop.
Detect all changes to a <input type="text"> (immediately) using JQuery
Apparently android keyboards have a strange bug with the keyboard so instead of attaching to the keydown event maybe try the oninput event.
I found more info on this issue here Capture keys typed on android virtual keyboard using javascript
Related
I'm currently trying to build a football quiz game in React:
https://www.footballerscv.com/
It works fine on desktop but I'm having issues with Android on mobile.
I have an input where I have a scenario in which I need to fire some function when the user hits backspace when the input is focused but is empty.
I can't use onChange method because that only fires when there is a value inside the input.
I wanted to use one of the methods onKeyDown, onKeyUp or onKeyPress but from my testing in Android chrome these methods don't even work along with backspace.
I know there's the native event deleteContentBackward but this appears to only work when there is a value inside the input.
Any workaround ideas for this?
Thanks
Scenario:
I have an web app where I need to capture all keyed input to the page in a central location. My first solution was to continually give focus to a text box so all focus would go through there. That works amazingly for desktop browsers, but causes the undesirable effect of causing the soft keyboard on mobile browsers to always be visible. Since my keyed input is coming from an external source, I don't want the keyboard visible until I request it. Since there's no direct way (that I've found) to do this, I was trying to give constant focus to a control that doesn't cause the keyboard to show. I was unable to find a control that didn't cause the keyboard to show, but would fire one of the key events (keydown/keyup/keypress).
Does anyone have a suggestion as to how I can catch all keyed input without displaying the soft keyboard?
Note: I can have a different solution for desktop and mobile if necessary.
Any help is appreciated!
Ok, so the answer was so simple, I can't believe it took me so long to get to it.
If you make a textbox readonly, it doesn't show the keyboard, but still fires key events. This allowed me to accept input from the external source without showing the keyboard. I also added a keyboard toggle button that simply hid the readonly textbox and showed the regular one.
If my application would have been different, I could have just added and removed the readonly attribute and applied focus again to have the same effect.
Thanks for all replies, including the ones that got deleted.
var keyedinput = "";
window.addEventListener('keydown', function(event){keyedinput += String.fromCharCode(event.keyCode)}, false);
keyedinput will contain the contents of the keyed input from the external keyboard-like device. Simply reference it as a global variable when needed. If there is an enter/esc key or and "end" key (sequence?) you can just check the corresponding keyCode to launch an action with the contents of the variable instead of appending to it.
I am developing a little Barcode Reading application for desktops intended to run on Browsers.
I use a usb barcode scanner and the barcode scanner basically sends KEY STROKES based on the barcode, and emulates a ENTER / RETURN key press after the sequence.
The user can not see the display and relies only on the barcode beep to confirm DATA ENTRY into the software.
This is where the problem might occur. For the jQuery app to process the barcode, the textfield must be FOCUSED at all time.
I would like to ask if all or any of the following can be achieved using jQuery or something close to it, and how?
Keep a textfield in focus at all times
Capture ALL the keys regardless of any textfield being focused -
where when I set the program to scanning mode, no textfield is shown
but rather all incoming keys are being captured by a JS function or
something like that.
Would appreciate some help.
Thanks
You could achieve 1 by setting a blur handler on the element, preventing it to lose focus (possibly by refocusing on the element).
Number 2 could be done by setting a keydown (or keyup or keypress) handler on the document, meaning all key events are going to be captured.
I have a small application that normally has a single visible text input, and pressing enter triggers a JavaScript method without triggering the normal form submission. Here is a very simple test case:
<form onsubmit="document.write('form submitted!');return false">
<input type="text">
<input type="submit" style="display:none">
</form>
On desktop browsers this works as expected - you enter text, press enter, and the script executes.
However, on Opera Mobile focussing on the text input brings up a virtual keyboard; if you enter text and touch "Done", the text is transferred to the input field, but the form is not submitted. There is also no "enter"
I'd like the app to behave the same way across browsers and devices, rather than make the submit button visible only in Opera Mobile.
Add name attr to the text input field and Opera will submit the form as expected
(it will show "Go" instead of "Done" on the virtual keyboard).
<input name="whatever" type="text" />
you have to:
give an id to your form
catch the "done" event under opera mobile, which I'm afraid I don't know the name
get the form with its id and call its submit() method in the done event.
Regarding to the event, I found out some informations:
Opera developers website:
Opera Presto has full support for DOM 2 Events with no exceptions.
http://www.opera.com/docs/specs/presto2.11/dom2/events/
w3c:
6.1.2.4 Virtual Keyboards and Chording Keyboards
Virtual keyboards are software-based sets of keys, in a variety of
different arrangements, commonly found on touch-screen devices; they
are often modal, with the ability to switch between different dynamic
sets of keys, such as alphabetic, numeric, or symbolic keys. Because
of the lack of physical constraints, these keyboards may present the
widest range of characters, including emoticons and other symbols, and
may have keys not represented by Unicode [Unicode] or by the key
values set defined in this specification. Wherever possible, however,
virtual keyboards should produce the normal range of keyboard events
and values, for ease of authoring and compatibility with existing
content.
http://www.w3.org/TR/DOM-Level-3-Events/
Basically it doesn't say anything about specific touch events, unlike under webkit technologies. So, you will have to catch the keypress/up/down, parse the keyCode/which attribute, compare to the one of "DONE" (some alerts will give you the good one) and then call the form.submit(); method.
rgds.
There really seems to be no way to catch the "done" key press in Opera Mobile:
it does not trigger keydown/keypress, so no keycode to catch
neither blur/focuslost (the focus stays in the field even after hitting "done")
change/input fire with every key type (so that's way before "done")
submit event never fires either
Seems to me like the only solution is really to show the "submit" button for "Opera Mobile" browsers.
I'm not even sure if this is possible, so apologies if it's a stupid question.
I've set up an keyup callback through jQuery to run a function when a user types in an input box. It works fine for English.
However when inputting text in Japanese/Korean/Chinese, the function isn't called until the user confirms their text.
Is it possible to detect that they've started typing, and access their as-yet unfinished text?
I'm thinking maybe it's an OS-level thing so Javascript doesn't have access to it.
Edit: I just realised that this works in Chrome and Safari, but not in Firefox (not had a chance to try it on Windows yet). So Chrome calls keyup and it's possible to get the text. But I'm still having the above problem in Firefox.
The compositionstart, compositionupdate and compositionend events might be helpful.
They help you detect when IME input is being used.
For example, consider using an IME to type か (ka) in Japanese.
The following events (in the order shown) would be fired:
k (IME visible) keydown, compositionstart, compositionupdate, compositionend, input
a (IME visible), compositionstart, compositionupdate, compositionend, input
enter (IME closed) keydown, input
Notice that the compositon events are only fired when the IME is visible (before enter is pressed). Also notice that the keypress event is not fired. This is only fired for non-IME input.
To access the user's unfinished text, you can use the data property of the event.
$('#input').on('compositionupdate', function(e) {
console.log(e.data);
});
For more info see MDN: compositionstart, compositionupdate, compositionend, InputEvent.
This is a known issue in Firefox, and what browsers should be doing isn't clear.
A possible method for working around this problem is demonstrated here, where the text field is polled for changes to the text (rather than relying on events).