bootstrap-tagautocomplete icon indicating copy to clipboard operation
bootstrap-tagautocomplete copied to clipboard

Inconsistent cursor placement on Bootstrap Tag Autocomplete demo

Open anvk opened this issue 11 years ago • 6 comments

Just tried the demo in Chrome Version 25.0.1364.172 http://sandglaz.github.com/bootstrap-tagautocomplete/

It seems that cursor is placed differently after autocomplete is complete. It depends on the line number where user is typing: First line will insert a tag, add a space after the tag and place a cursor after Second line will insert the tag and then place a cursor right after the word Third line will insert the tag and then place a cursor one character before the word end .... And so forth

-- Screenshots attached Screen Shot 2013-03-27 at 12 19 52 PM

Screen Shot 2013-03-27 at 12 22 01 PM

Screen Shot 2013-03-27 at 12 22 41 PM

anvk avatar Mar 27 '13 16:03 anvk

Thanks for reporting this. I'll take a look at it when I get a chance. Meanwhile, if anyone wants to take a crack at it, let me know if I can help.

NadaAldahleh avatar Mar 28 '13 18:03 NadaAldahleh

I had this error while working with Redactor [ imperavi.com/redactor ]. I had to hack the keyup/keydown functions in the main js (boostrap-auto...)

But now I'm getting the same problem in firefox (I fixed it in Chrome)

javierder avatar Apr 16 '13 15:04 javierder

I noticed the same problem. In my opinion, it's related with the line breaks - more line breaks, the more caret is placed backwards.

siimv avatar May 23 '13 18:05 siimv

So I've started looking in to this, and it seems there is a disconnect between setCaretPosition and getCaretPosition

I've written a failing test (FF, IE, and Chrome) that I believe demonstrates this, it's in my fork of the code https://github.com/mgray88/bootstrap-tagautocomplete/commit/e40903a4cbcc7090ca0903e7d431a5a4bf8d41de#L0R454

My knowledge of ranges, is however, very little (also the first test I've written). So @NadaAldahleh if you could take a look at this and let me know what you think that would be great.

mgray88 avatar Jun 24 '13 11:06 mgray88

I think this is related, for what it's worth. In the return function

updater: function(item) { return item+' '; };

we expect a space to be inserted after the item selection. I see the space in the html, but I don't see the cursor set after the space in chrome, and in firefox I see the cursor position revert to the end of the selected item on the first keypress. so it's inconsistent, and esp bad in ff where the user thinks there is a space then it disappears.

So I removed the +' ' in the updater return statement, now the user has to type the space.

Note: i'm also noticing there is an html line break
inserted in the div in the example, and this seems to help with the firefox issue above, but I'd prefer a consistent experience across browsers.

I regret I haven't had a chance to look into the root cause more.

and awesome work on this - it's great!

EDIT: 8/9 the css prop / val "white-space: pre-wrap;" will fix the issue of the trailing whitespace being removed in chrome. However it doesn't help with this ticket overall, b/c "white-space: pre-wrap;" collapses newlines, so unless you have a space before a newline the autocomplete div won't display on any newline. this not-so-old post was somewhat useful http://css-tricks.com/almanac/properties/w/whitespace/

jonnymacs avatar Jun 25 '13 05:06 jonnymacs

Looks like setting the css prop / val "white-space: pre-wrap;" as suggested by @jonnymacs and removing "br" from line 62 in "caret-position.js" fixed the problem in FF and Chrome for me.

kolucciy avatar Jul 13 '14 21:07 kolucciy