I have a web page with an odd behavior on part of it.
On most of the page, the input tags work just the way one would expect.
Here's an input tag I put in to test:
<input name="vanilla1" value="vanilla" />
In one part of the page, I can click on the field to edit it, but only at the front of the field. So, if the input tag had a value of "vanilla", I could click in front of the "v" and start typing or deleting. But it won't let me click between the two "l" characters and start typing.
It's not easy to just post a full working sample, I would have to retype by hand a lot of code.
If I wanted to get that behavior I don't have a clue of how to do it.
Any ideas of what to look for that might cause this?
It's obviously not disabled or readonly because I can edit it.
When I inspect the problem input tags in the IE DOM explorer, they don't look any different from the input tags that work as expected.
There's javascript, html, angularJS and dojo, plus the esri gis api css libraries in the technical mix.
A few more observations:
In IE, when I click on a working input tag that already has a value in it, I get a little X show up on the far right of the input box. If I click on the X the field is blanked out. On my problem input tags, when I click on them, I get the X but clicking the X does not work. So I appear to be accessing the right object.
When I inspect the object, everything looks normal. No javascript events attached, it's not read only or disabled.
Isn't it like covered by another node or something like that?
Did you check it in all browsers or only in IE?
Try to open Chrome DevTools and click the "Select an element in the page to inspect it" (top left corner of the DevTools window, CTRL + Shift + C shortcut on Windows) and hover over that input. See if there's possibly any element that may cover it. If there's - voila! Remove that overlay and you're good to go. If not - I don't have any ideas for now.
Related
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!
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.
I have a ContentEditable div that I'm using to try to make a WYSIWYG editor (using Chromium 83)
The problem is that when hitting enter to make a new line it's really inconsistent with what it inserts into the div, which causes the cursor to act really weird when pressing Up or Down.
For example when you press Up it sometimes jumps halfway up the page for no apparent reason, and other times it just jumps up to the nearest div tag that it can find, instead of just moving 1 line up.
My question is what can I do, either by handling enter presses or changing something about the editor div, to make the cursor just move up and down line by line like a regular text editor? (even if the line is blank)
It seems like wrapping every line in a div would work, and that's what Chrome is supposed to do by default, but when spamming enter Chrome only inserts a div tag sometimes.
I've tried:
Inserting a unicode "newline" character on enter (which breaks the native WYSIWYG editing, for example pressing enter won't carry on a list or clear formatting)
Changing the default paragraph separator to <p>, still only places them randomly, not every line
Inserting a <br> on enter press, only places it once
Manually inserting <div></div> tags, doesn't work
Executing document.execCommand("insertLineBreak")
And all of these either don't work at all or still cause the cursor to jump up to random places in the editor when pressing Up or Down. I just want it to move up and down 1 line like regular text editors.
I even see this happen in modern WYSIWYG editors that I found online, and can't find a fix anywhere.
Any help appreciated
Edit:
I went and posted this question on the Chromium-Dev google group, and the post editor for Google Groups (the old version, not sure about the "new look" editor) shows the behavior that I'm looking for, so if anyone knows how that works that might help
Edit 2:
Someone on Reddit referred me to ProseMirror and it's a very well-behaved WYSIWYG editor and I ended up using that for my project.
I try to focus an element of an email field in this webpage, with the following code:
document.querySelector("#user_email").focus();
While manual focusing with either clicking on the field with the mouse or using tab works, the focus() method fails to create the focus, as it seems both from the fact the CSS doesn't change, and the console returns "undefined".
As a newcomer, I ask why?
When you're calling focus() from console, focusing won't happen immediately - you have to go back to the site (close console). When you go back from console to a website by clicking on a website, focusing won't happen. Close console using shortcuts or use setTimeout to delay focusing to give you time to go back to the website.
Digital Ocean's input boxes are focusing fine for me. The undefined basically means that nothing is returned from your expression. For example if you type var a = 123 it'll still say undefined. Also there is no special CSS styling on these input boxes. You might be getting confused with the ones in their control panel.
UPDATE: OP was getting confused with Chromes default input styling.
You should try with document.getElementById('user_email').
document.getElementById('user_email').focus() ;
<input id="user_email">
This is a 2 part question:
1)
click on one of the demo dropdowns on this page. when you tab over to the next input, the text is selected/highlighted in firefox. how can i prevent this from happening?
2) bonus: can you review my code that is hosted on google and tell me what i can improve?
Well, that is just default behavior on Firefox. A possible workaround is to have the input fields execute a JavaScript or jQuery function on select, have the function blur the field (which would deselect the text) and then refocus on the field. Very basic and I'm sure it'd need a couple extra hacks. Unfortunately without scripting, no there is nothing you can do to prevent that.
I honestly recommend that you leave it alone. That functionality was put in place so you wouldn't have to use your mouse when typing into forms, hitting tab would select all the text so you can easily retype it or hit the right arrow key to go to the end of the field. Removing the functionality will only irritate some of your visitors. If they're using the tab key to get to the next field, they probably want that functionality.