virtual keyboard popup onfocus of a text field - javascript

EDIT: this feat is impossible. since then I have given up. I shall not delete this question, but rather leave it up right here so future users can see a relevant result to their query on google regarding a similar thing
Goal: Either make a textarea bring up the virtual keyboard when focused(with js) OR make a input[type=text] have multiple lines AND bring the virtual keyboard
(I believe answered here but with unsatisfactory results.) (If anyone knows of fully compatible ways to multiple-line-ify an input[type=text] please tell me)
Expected results: virtual keyboard popup when focusing the input OR textarea fields (via javascript with no user trigger).
Real results: caret appears in text field but keyboard remains unseen.
Here's what I'm trying on a textarea:
document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent(click);
Please don't make irrelevant comments about my code organization
#WaisKamal can you show me your code since you said it works?
HTML(no CSS):
<textarea>textarea</textarea>
<input type="text" value="input" />
<script>
//document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent("click");
document.querySelector("input").focus();
document.querySelector("input").click();
</script>

You can use inputmode to determine how a virtual keyboard behaves
<textarea>textarea</textarea>
<input type="text" value="input" inputmode='text'/>
<script>
//document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent("click");
document.querySelector("input").focus();
document.querySelector("input").click();
</script>
Edit
I'm still testing this out, it seem to give some mixed results in the jsfiddle that I'm currently testing right now, sometimes it works and sometimes it does not
*Edit 2 *
It seems to have the same results without specifying the inputmode It does not work the first time the page loads but if I click somewhere on the page, it works every time I click run.
I'm only speculating here but it seems like the keyboard does not pop up without the page receiving some user interaction first, maybe this is intentional for security reasons but I didn't find any docs saying so.
As for you other question you can give a div or other container element contenteditable to have multiple rows / any dimensions you want.
-
Here is another questions and some answers to the same problem though a bit old, Show virtual keyboard on mobile phones in javascript
-
All in all it does not seem possible so show a virtual keyboard without some user interaction.

Related

Change text Input control of mobile keyboard on website

I have a text input field on a website that people have found confusing. To use it you have to hit the enter key on your keyboard, but since the mobile keyboard shows a return button people think it means new line and not submit.
I noticed that flutter has textInputAction property that can be changed, I was hoping that there may be something similar in html, css, or js that has similar fine grained control.
The only thing I have found is that type="search" guarantees a button that won't be return. This is a possible solution as the button I see for search fields is a generic checkmark, but I'd like to avoid mislabeling my input type. As well I'd like to avoid a magnifying glass icon which I believe has been and may still be used for some devices.

JS Greasemonkey Input Text Box

I'm a newbie JS programmer, just trying to do some automation here and there with extensions like Greasemonkey/Tampermonkey/Violentmonkey.
I ran into a wall that I can't find a solution, already tried to search for it for days and still can't figure it out.
The problem is this: there's page buttons (like a book), it can to go back, forward, and set a number to skip to X that page.
I can click on both back and forward with no problem. My only issue is making use of the input box (not sure if that's how it's called).
The box works like this: you set any number inside and press ENTER (only way to confirm/submit the value change) and them it'll skip to that page if the page exists.
One weird thing for me is that I tried changing it manually from 1 (default) to 3, them setting to 2 on script (with x.value) and when I confirm it manually, it goes to page 3 and not page 2 (even though it's showing 2 on UI and also on .value). So I though at least the value set I got, but it seems that even that I couldn't make.
Also changing the value="1" on DevTools to anything else doesn't change the UI and also don't register the input change, since when I press enter it just ignore my value.
This is the HTML shown on DevTools of the input box:
<input class="number" value="1" style="width: 40px; height: 40px; text-align: center;">
I'm not using jQuery (simply because I don't know how to use it), but if it's necessary I can learn!
Screen of the HTML structure on DevTools
Console.log with some info about the element I could search online
I don't know anything else I could provide to help further assistance.
If there's anything, please let me know and thank you for helping!
With #wOxxOm's solution I was able to do it!
All it needed was his solution (see comments) to change the inside value of the textbox and them a el.dispatchEvent with enter on it's key made the submit work!

How can one stop Safari from focussing on form fields labelled Username or Password when document loads?

Whilst it might feel that this question should have been asked before, many times, the closest solution I can find is less than helpful, referring to 'snowflakes'. There is, however, a comment that highlights where the problem is a genuine issue.
When developing a form for a site administrator to use, any page which is set up to allow that administrator to initialise the username and password for a user seems to trigger Safari's aggressive Autocomplete / Keychain behaviour, which pulls the form's focus onto the Username field once the DOM is complete. There are some solutions to this, but they are not particularly elegant - redoing the form layout, for example, so that the Username field is the very first one or so that usernames and passwords are handled on a totally separate page / tab. To my mind that's the browser dictating the page, which is the wrong way around!
In my case, I'm pulling the form's construction details from a table of constraints so that additional fields can be added later and the form for that table amended automatically without rewriting code. This approach means that javascript based solutions are not 100% compliant with the idea of having no pages that require special measures - it's nicer to fix this at HTML or CSS level. Obviously this might not be possible; just ANYTHING that works to fix this annoying habit would be good.
I could kludge the effect I required by adding the following dummy input field right after the main body form tag:
<input type="text" id="defeatbox" style="position:absolute; top:-1000px;" autofocus />
And then changing the focus to it 300ms after DOM ready.
$(document).ready(function () {
setTimeout(function () {
$('#defeatbox').focus();
}, 300);
});
This is a REALLY kludgy way of doing it. The dummy field can't be hidden, the length of the timeout has to be determined by trial and error, and is dependent on the size of the page, and presumably the browser and the CPU speed. It also caused the first "autofocussed" box to "flash" briefly on the screen.
The more generic code:
setTimeout(function() {$('form:nth-of-type(2) *:input:first').focus();},300);
didn't work if the autofilled/autofocussed element was in that same form (mine is the second form as there's a search box on the page that's drawn first). I could autofocus the search box in the first form using this method, but couldn't pull the focus to anything 'generic' in the second form which is the one in the main body of the page.

Clear button for form input field using JQuery and JQTouch

I have a site built using JQTouch and want to add the little cross
buttons within text input fields to clear out text on press.
I've tried emulating Google's technique from their google.com iPhone
site. Also I've read about that approach over here
little 'x' in textfield input on the iphone in mobileSafari?...
I have this partially working. But whether and when a press on the
cross button is registered seems unreliable.
I've created minimal code to test this:
with JQTouch -
http://hogtownconsulting.com/clearquery/index.html
without JQTouch (or any other JS libraries) -
http://hogtownconsulting.com/clearquery/index-no-js.html
I'm not certain that it's an interaction with the JQTouch library
that's causing these problems. But the version without JQTouch does seem more responsive to taps on the cross button. Any suggestions on how I can get this feature working
properly would be much appreciated. Thank you, Patrick
You get that little X automatically if you name your input type = search.
<input type=search name=s>
This article will help you plenty.
CSS Tricks for WebKit
If you don't want that input to be a type = search, then you will have to fake it out a bit.
1. create a div and round it using css.
2. put your input in there, and remove webkit decoration, shading etc.
3. put a SPAN with your X image in to the right of the input. add an onclick to that image which clears your field.
<div><input type="text" id="thing"/><span onclick="clrField();"><img src="x.gif"/></span></div>

Safari Javascript Issue

I am currently working on a Javascript program for my company (Leader Technologies) that is used to register products for Logitech. The URL for that is :
http://wwwtest.onlineregister.com/logitechreg/
My program looks totally fine on everything single web browser (including IE 6) that I have tried except Safari 4. On Safari 4, after a location, language and product category have been selected, when the actual product menu is clicked (id=WHPR), the div responsible for displaying the product is shown, but the drop-down selections are still visible. On all other browsers, the drop-down and the possible selections inside it in hidden (which is the intended behavior.)
Directly, my question is can I hid this drop-down successfully in Safari 4 WITHOUT completely emptying out the drop down and then repopulating it with only the selected value? I would rather not do this if at all possible, but if it's the only way to accomplish my goal then I can change the site additionally.
I believe the problem is where I set the listeners on the <select>:
<select id="WHPR" class="ui-formulate-ignore" style="width: 280px; visibility: visible;" onchange="whprChanged(this);" onfocus="displaySelector(form, document.getElementById('WHPR')); document.getElementById('imageHolder').focus(); this.blur();" name="WHPR">
Thank you all very much for taking the time to help me. I really appreciate all the help available on this site.
-Brian J. Stinar-
Not to pick on your style, but attaching listeners inline like you're doing is not very clean. Why not take advantage of jQuery's ability to deal with any browser discrepancies? The page you refer to is already loading it.
See http://docs.jquery.com/Events/bind
I think it's some kind of a bug in Safari - for example if you do .focus() nof for the DIV but for another input element like a textfield, then after clicking the selectbox both would have the focus (or actually, the focus would stay in the selectbox and the textbox would only seem to have the focus by having thicker border than usual).
Anyhow quick and dirty methot to achieve the goal would be removing the selectbox from the page (display: none) and then bringing it back (display:inline).
replace the this.blur() with the following command
this.style.cssText='display:none';var select = this; window.setTimeout(function(){select.style.cssText='display:inline';},1);
If you don't use a delay then it doesn't work - the removal and retrieval of the element need to be in different scopes.

Categories