search

deshiknaves / caret-pos

Locate the current position of the caret. A plain JavaScript version of Caret.js.
MIT License
117 stars 13 forks source link

Bug: Caret position isn't accurate #19

Open SeanBannister opened 4 years ago

SeanBannister commented 4 years ago

Thanks for fixing #14.

Here's a minimal demo to show a bug I'm experiencing: https://jsfiddle.net/8b3e4hmw/3/ In it I create a fake caret (in red) and position it where caret-pos says the caret is, if both positions are the same the caret should cover the eixsting caret. In certain locations but not all the fake caret is in completely the wrong location.

I've tested in chrome and firefox, both display the bug but on different lines.

Sorry I haven't had a chance to debug myself.

image

deshiknaves commented 4 years ago

It's because <span id='caret'>&nbsp;</span> is before the textarea and once you click in it, that space disappears. I'm not seeing an issue after the first time. I've updated the fiddle to move the cursor to the bottom of the textarea

SeanBannister commented 4 years ago

Here's a demo with the caret at the bottom and a screen shot of the bug: https://jsfiddle.net/mfwjt4e2/ image

My use case is for a chrome extension where we're injecting this in 3rd party websites and checking the location of the caret to display a drop down as they type. I get the feeling from your last message that this method might be a bit touchy and I'm going to run into issues?

deshiknaves commented 4 years ago

@SeanBannister. No, that's not quite accurate. The reason why your first example didn't work is because the position of the textarea in relation to the calculation was changing. Because the span was moving changing where the height of the textarea is.

I can't reproduce your bug on your fiddle on any of the 3 browsers that I've using. They are all next to each other.

deshiknaves commented 4 years ago

The only way I can get it to do that is if I select a bit of text and then place down arrow. Then the red one is where the selection began and the cursor is where the selection ended. That is not something that this library supports internally. However, you can get call it again to get the current position if you need that.

SeanBannister commented 4 years ago

I can see this bug every time on first and second click without making any selection or using the arrow keys. I just opened firefox to see if the bug happend at the same location and it doesn't, it happens at a different location it took me 15+ tries to find a location where this was happening in firefox (wasn't happening until second paragraph) and now I know the location and I can click there every time and see the same thing.

I just tried to do some debugging to figure out what was causing the issue and the first thing I tried was changing the width of the textarea via cols="150" and suddenly I couldn't reproduce the bug in Firefox. Went back to Chrome and the bug was only showing at the end of some lines (I'm literally clicking hundreds of times to test this). I also tried setting the font-size to 13px and that caused this bug to only show twice in the textarea in Chrome.

I've also just tested on a second computer.

Chrome 83.0.4103.61 Firefox 77.0.1