prevent the cursor in Chrome's textarea from jumping to the top when the user inserts a newline

[andrelsm]

hi, WebCoder,

It's a Chromium(Blink)-based browsers misbehavior (bug?). But take a look at this:

https://www.debugcn.com/en/article/41179722.html

[ ] andrelsm

[KaiWilke]

Solution is simple.

1.) Intercept Enter onKey event
2.) Save scrollTop value before calling execCommand to send Enter on behalf.
3.) Calculate scrollTop after execCommand has been run.
a.) Check if the current carrot position is above or below current scrollTop and adjust scrollTop to move the cursor back to the currently visible area.
b.) If the current carrot position is still inside the visible area, then always restore the saved scrollTop position. This will have no effect at all, unless the jump bug occurs causing the annoying scrollTop change...

Cheers, Kai

[andrelsm]

@KaiWilke I've added your code for indentation and brackets completion as a plugin and it fixed this browser misbehavior. Thanks a lot. (Please check my comment on the topic).

my best regards, andrelsm

[KaiWilke]

You mean your "enter on last line not working" comment?

Cheers, Kai

[andrelsm]

Yes, The cursor caret get out of view when we hit [enter] in the last line or f ex "{|}" near the last line. um abraço sent from MailDroid

…

-----Original Message----- From: Kai Wilke ***@***.***> To: WebCoder49/code-input ***@***.***> Cc: "André Luís da Silva Monteiro" ***@***.***>, Author ***@***.***> Sent: Sat, 16 Dec 2023 5:01 Subject: Re: [WebCoder49/code-input] prevent the cursor in Chrome's textarea from jumping to the top when the user inserts a newline (Issue #72) You mean your "enter on last line not working" comment? Cheers, Kai

-- Reply to this email directly or view it on GitHub: #72 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[KaiWilke]

@andrelsm : I pointed out in my post, that the use of "Padding-Top" makes it hard to calculate the exact position the scrollTop has to move at the end of the visible area. My own solution does not use any paddings on the textarea window, so it does not add any offsets to account paddings.

The relevant lines to handle the scrollTop at the end of the window are.

		else if(cp>=st+ch)st=cp-ch+0.25;
		EE.scrollTop=st;

Which means if the calculated carrot position (aka. #lines*lineHeight) is greater than current scrollTop + clientHeight, than set new scrollTop to carrot position - clientHeight includings an hardcoded offset of 0.25 to get on an overage the same results as you would get when you hit the cursor-down key.

If a Padding-Top of 10px is used, you may change the lines to become a...

   	else if(cp>=st+ch)st=cp-ch+0.25+10;
   	EE.scrollTop=st;

... you may want to tweak the +10 to give the same results as hitting cursor down.

Note: I've tested it with different Padding-Top settings and never found a stable formular that will work with any given Padding-Top settings. At some point the calculated scrollTop started to not match the hitting cursor down position anymore. :-(

BTW: I've attached my Prism/Textarea solution to show how the 'Enter' code works out with 0px Padding-Top. My Editor box is not based on code-input at all. Its purely based on the css-tricks.com posting made by @WebCoder49 back in the days, but then radically customized until i was happy with it. My 'Enter' intercepts are very different to the latest version of code-input. Play with both and you will notice the differences. Hold enter till 100 lines are created, move cursor at the very top again or somewhere in the middle and hold enter again, move cursor outside of the currently visible scrollTop (upper and lower) and hit enter again. Compare enter on last visible line with cursor down scolling. Try out enter between braces on last line or even outside of the currently visible scrollTop. Now change the size of the Textarea by either clicking on those +/- buttons or via drag'n'drop and try again. Working everything as expected? You may also want to try out my TAB'ing sequences. Compare the behavior with Notepad++ You miss anything? What would you change?

Original Posting: https://css-tricks.com/creating-an-editable-textarea-that-supports-syntax-highlighted-code/

Code-Input Auto-Intent: https://codepen.io/WebCoder49/pen/WNgdzar

My F5 iRule Debug Page Solution: Debug Page.zip

Cheers, Kai

[andrelsm]

brother this fixes it: textarea.blur(); textarea.focus(); regards André Luís  

[WebCoder49]

Thank you for this! I will look at it and implement it in the CSS-powered more lightweight scrolling that the library is using now once I return from holidays and hopefully release it in January 2024.

[andrelsm]

Happy holidays and happy new year!

[KaiWilke]

@andrelsm

I did a quick test with .blur() and .focus(). I changed my code to become this...

	//let ch=EE.clientHeight,l=getComputedStyle(EE).lineHeight.slice(0,-2)*1,cp=(c.slice(0,s).split('\n').length+1+bb)*l;
	//if(cp<st+l)st=cp-l*2-bb*l;
	//else if(cp>=st+ch)st=cp-ch+0.25
	//EE.scrollTop=st;
	//EE.scrollLeft=0;
	EE.blur();
	EE.focus();

It solves a lot of problems with as little as possible code. But it does not solve the Chrome bug and also causes additional unexpected carrot jumps to the center of the textarea (e.g. hitting enter between pair of baces on last line, if carrot is outside of the screen and somehow also sometimes in the middle of the screen which may be related to the chrome again).

In the end, I prefer a stable editor and carrot position more than having as little as possible code footprint. So I'm gonna keep my rather complex scrollTop calculations to get a smooth scrolling behavior.

Cheers, Kai

[KaiWilke]

Happy holidays and happy new year too!

[andrelsm]

@KaiWilke

try this

st = ta.scrollTop;
...
document.execCommand('insertText', false, r);
ta.scrollTop = st;
ta.blur(); ta.focus();

(ta is your ele)

it fixes chrome bug with no complex calculations. (Be aware that computed style lineHeight may be "normal" or etc.).

[KaiWilke]

@andrelsm

Works much better and also fixes the Chrome Bug. But it still causes some jumps to the center of the textarea, if you do:

1.) Create empty lines until scrollbar kicks in, move carrot up a couple lines and then press enter again until you are back to last line. Then hit enter between two braces.

2.) Hit enter on a line which is somewhere above/below currently visible textarea.

Its up to you which behavior you like more, or if you are willing to add more code to handle those edge cases.

Be aware that computed style lineHeight may be "normal" or etc.).

My code is not a generic solution. Its pretty much tailored for my specific needs and I'm the only one who is changing any CSS. My productive code even skips getComputedStyle() and uses a fixed '15' for lineHeight calculations. But for Code-Input this should be definitely a thing to consider.

Cheers, Kai

[WebCoder49]

Another thing that seems to fix it (that I found by accident!):

• Make the code-input element scrollable rather than the textarea.
• This will be released in the next version of the library.

[andrelsm]

Great! Thank you once more ... um abraço sent from MailDroid

…

-----Original Message----- From: WebCoder49 ***@***.***> To: WebCoder49/code-input ***@***.***> Cc: "André Luís da Silva Monteiro" ***@***.***>, Mention ***@***.***> Sent: Sat, 20 Jan 2024 14:17 Subject: Re: [WebCoder49/code-input] prevent the cursor in Chrome's textarea from jumping to the top when the user inserts a newline (Issue #72) Another thing that seems to fix it (that I found by accident!): * Make the `code-input` element scrollable rather than the `textarea`. * This will be released in the next version of the library.

-- Reply to this email directly or view it on GitHub: #72 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[WebCoder49]

Another thing that seems to fix it (that I found by accident!):

• Make the code-input element scrollable rather than the textarea.
• This will be released in the next version of the library.

This has been implemented in pull request #76