I need a way of scrolling to the caret position in a textbox no matter where the caret is. The problem I am having is very similar to this one:
Possible to scroll caret into view inside a single HTML text field with JavaScript?
The solution to the other question I mentioned is given as adding an extra character at the end (which sets the caret position to be at the end of the text) and then simulating a backspace key press (which scrolls to the end of the text). It works fine while the user keeps typing, the text scrolls properly since we are always adding characters to the end of the string. However, if the user, for example, clicks somewhere in the textbox, it sets a new caret position, and if the user then starts typing from the new caret position, the extra key/backspace solution does not work properly as it always takes us to the end of the string.
I need a way of scrolling to the cursor position while the user is typing, no matter where the cursor is. Some more additional information: While using Firefox, setting the textbox value in my Javascript code scrolls to the leftmost position in the textbox although the cursor is at the end. The illustration in Possible to scroll caret into view inside a single HTML text field with JavaScript? shows what I mean. It does not happen on IE, Chrome, Safari. So the issue mentioned in this question a problem for me in Firefox only. Any ideas?
Related
I have a textarea with a lot of text and a vertical scrollbar. When I move the cursor beyond the visible area (imagine having a long document, and then pressing down arrow many times until cursor goes off screen), the browser will automatically scroll the cursor into view, so it always remains visible.
How do I prevent this behavior? I need to be able to move cursor beyond the visible area, without it being autoscrolled.
(technically, it's not a textarea but a React-based text editor, in dom it's a div with content-editable set to true, not sure if it matters)
It doesn't appear this is possible. From the spec:
It MUST be possible to put the caret in any of the Legal Caret
Positions programatically and for the caret to be visible in these in
any editing host that is in the "events", "caret" or "typing" state.
https://w3c.github.io/editing/contentEditable.html#caret_positions
"MUST put the caret" & "MUST be visible" indicate this.
I am about to write a input system for a web application that is a bit more complex. We have Labels in our text that are weather displayed as a bootstrap label (when the contenteditable div is blured) or displayed as handlebars e.g. {{firstname}} when the text is focused.
The changing in states is done by jQueries $().html(content) where I change the content based on the source when I focus the text field.
The problem is: if I click the text, I don't want to need to click a second time to place the cursor, because the text changed. It works as long I don't click inside of a tag but inside the contenteditable root element. but if I click inside of a tag inside the contenteditable, the cursor is not set.
my idea was to get the mouse position when clicking the contenteditable and then set the text cursor to exact that position when I have changed the text. But while I know, how I set the cursor to a specific offset inside a text node, I have no clue how to get this necessary offset when clicking. any ideas?
Edit: Here is the behaviour in a little screencast: https://youtu.be/RZvHxxM6wsQ
Edit2: Here is the problem reproduced on the smallest kind of working example:
https://jsfiddle.net/8z5Lnxef/3/
This one's a challenge:
Suppose you have two text inputs, as in this fiddle. When the user "scrolls" inside of one (e.g. by moving the cursor to the far right or left), I'd like to "scroll" the other so that it stays in sync. Can this be done, at least in modern browsers?
I would change the text that isn't being input to an IFrame. If both need to be inputs, then dynamically switch your element from iframe to input when it is focused on/away from.
In the input box, you can find where the caret is by using the selection properties; then the IFrame can then be scrolled using scrollTo.
I'm afraid I don't have a complete solution for finding out exactly the scroll state of the input box.
I am trying to create a javascript code editor just for learning and I am doing a great job so far. The only thing is that I wanna place the autocomplete box in a position relative to the text cursor in textarea. So how can I determine the cursor position relative to the upper left corner of the window ?
Something else please, how can i capture the tab & enter keys press in a textarea ?
I am using a semi-transparent textarea (semi to keep the cursor blinking) with underlying div to enable code highlighting later on. Is this the best technique to do that ? Or there is a way to make textarea accept rich text or HTML ?
I suspect that you can do all that without a textarea. Read up on the contentEditable property. Here's a demo. This is how the Google Docs editor is implemented, incidentally. And here's a stackoverflow question dealing with finding the cursor position in a contentEditable div.
I have an HTML textarea as a basis for a small text editor running inside Chrome, which includes search functionality (as I need search features beyond what the browser offers). For longer texts, this means I need the JavaScript to scroll to the correct position after selecting the found text. This works fine by calculating the font's line height times the found text's row number (the latter I get by counting line breaks) and then setting textareaElement.scrollTop... but only when the textarea is set to wrap="off". When it wraps, as I sometimes need it, I cannot simply count the rows by counting line breaks, and my scroll position algo will be off by a bit.
What can I do to get the correct position of the found, selected text?
I've tackled this issue for the search feature of the logging console in log4javascript. My code surrounds search results in tags whose style properties are changed as you flick through search results. Initially I called scrollIntoView() on the current search result span but I think I had problems in certain browsers (log4javascript supports IE 5, for example) and ended up writing my own scrolling function based on the offsetLeft and offsetTop properties of the span and the scrollLeft and scrollTop properties of the container. I suspect scrollIntoView() will work fine in Chrome though so you should be OK just using that.