Cursor lagging input

[Bertg]

I found this behaviour on both the current demo page (see gif) and it's also happening on the latest (beta) build.

Wha tis happening that at reasonable speed the cursor seems to be lagging the input of the component. However the input is still OK. However at fast input the typing might actually get compromised.

We have a bunch of other components using the same "controlled value" mechanism where this is not happening.

This was recorded with the latest Safari on OSX. We do not see this on latest Chrome.

Any suggestion?

[twe4ked]

I'm seeing this on Safari too. Nothing to add just that it's not just you!

[Bertg]

@JedWatson is there any other type of info we could provide to help solve this?

[Bertg]

I did some extra research and found the same behaviour on react-select-autosize a component used by this library.

I reported the ticket there as well. JedWatson/react-input-autosize#36

[JedWatson]

Thanks for the report, and sorry I haven't had a chance to look into it yet. I'll try and get to the bottom of it ASAP; if you're able to isolate what's causing the delay (may be due to slow/excessive re-rendering?) that would help!

[Bertg]

Hey @JedWatson

It's quite difficult to spot this in Safari, but I did figure some things out:

• if I force a min-width on the DOM input element (renderd by react-autosize-input) then the lag does not happen until the string "hits" the edge of the input
• The issue does not happen if the cursor is not at the last character

Some possible fixes (haven't verified):

• Create a few pixels of lead space on the input (In safari only maybe)
• Resize before changing the value (would probably require 2 passes to render the change)

Maybe, - as an alternative to figuring it out - a different approach could be used?

In stead of dynamically increasing the width of the input, let the input take up all the available space in the select component. This would have as a disadvantage that "resizing" react-select component would be impossible.

[alexanderchan]

@Bertg does the same thing happen with react-selectize for your use case? If it works, perhaps the method that is used there is an option. It reads the scroll-width of the input element for evergreen browsers.

[Bertg]

@alexanderchan It seems the issue is not happening there. It also seems that the input element is doing the same "resizing" as react-input-autosize. //FYI @JedWatson

[JedWatson]

Hmm, so this whole thing is really only necessary when multi={true}, to get the wrapping to work. Maybe I can disable use of react-input-autosize altogether when multi={false} as a short term improvement. Will see what I can work out with your other suggestions, @Bertg, thanks!

[Bertg]

That would work indeed. However our case specifically if for the multi version :)

[JedWatson]

Haha well then. No shortcuts for me :)

[alexanderchan]

It seems that react-selectize isn't using a hidden DOM element for it's calculations (except for IE browsers where we can see it does some document appending), it uses a direct ref to the input (search) area. I could be wrong as my livescript reading is not the best.

If I am reading it correctly, it then sets the width to 0 pixels in componentDidUpdate. Somehow this sets scrollWidth back to the length of the content. It then reads back the scrollWidth in order to set the width to 2px + scrollWidth.

I've put together a small demo in jsbin of just setting and resetting the scroll width. It works on a mac firefox, chrome and safari. I'll try to test it some more with styles later. IE edge blows up, so I guess another hidden element would still need to be rendered for IE.

http://jsbin.com/qeritin/edit?js,output

[Bertg]

@alexanderchan Thanks for the investigation! I've been playing with your demo, and it works great.

What I found, is that the extra 2 pixels are not needed, and that it still works if i make the component pure (http://jsbin.com/yanabivana/edit?js,output).

In case this doesn't work for IE, what i would suggest is to make a "proxy" component, that depending on the browser loads the correct component for that browser. This way multiple implementations can co-exist, without any complex code.

[alexanderchan]

@Bertg thanks for refactoring, it looks good. I hope there is something simple that can be done for the IE case but maybe some of the other libraries are solving the same problem in a clean way.

It's probably preferable not to reach out as far as window if possible to create and destroy a hidden element but let's see what solutions are out there. I'm curious to see how Brian Reavis' original jQuery based selectize handles sizing. I'll try to understand the code if I get a chance.

[Bertg]

Any update on this issue?

[balupton]

Not sure if this is useful, but happens to me every time on the demo, screencast: https://youtu.be/9Fu3r_e5Vug

http://alexkuz.github.io/react-input-enhancements/ works perfectly for me

[Pixlschmied]

Hi, we're also affected by this problem. Is there any workaround / fix so far? Using v1.0.0-beta12

[JedWatson]

I've just published an update to react-input-autosize that should fix this, the update is just a patch bump so it should be automatically picked up by new npm installs

Would anyone who's experienced this please try out the demo here and let me know if you still have any issues? thanks!

[Pixlschmied]

Thanks! I tested it on IE 11 and it works.

[lgrapenthin]

I am still experiencing a very similar issue reported by other users on IE 11, both for the demo page and beta13. The input clear pseudo element is not properly removed by the provided CSS (-ms-clear) which breaks the layout calculation so that the content does not fit the input field anymore. If disabled by the user (since you provide one already), the input basically works, but for each entered character it shortly but notably shifts out of the left border of the input and back.
If there is an older version that I could downgrade to, please let me know.

[stasgavrylov]

I also experience some sort of this bug in IE11. When you type relatively fast, the input jumps back and forth (sorry, can't tell more because I test it on a laggy virtual machine). Also, in the end of the gif you can see the default IE's ::-ms-clear appearing, but this can be easily fixed with CSS.

[mikecousins]

We're seeing the same problem as @stasgavrylov. It's pretty harsh for our IE users. It's jumping back and forth. It's not as bad as the old version where it actually moved the cursor around and then you got out of order characters, but it's still pretty bad.

[freeranger]

Same here as @stasgavrylov and @mikecousins using IE11.0.9600.18524.
@JedWatson Are there any plans to fix this bug? Thanks

[jwilander]

Experiencing this (the same issue @stasgavrylov posted) with IE11 as well.

[edward93]

I was also experiencing this issue on IE 11. Setting autosize={false} did job for me.

[alabels9]

I am also experiencing this issue on IE11 (11.0.9600.18537) similar to @Bertg and @stasgavrylov , but for me the cursor shows the character then deletes it again. I have the latest version (1.0.0-rc.5), and I tried @edward93 suggestion for autosize={ false } with no improvement. Any other suggestions? (Works fine on other browsers)

[bladey]

Hello -

In an effort to sustain the react-select project going forward, we're closing old issues / pull requests.

We understand this might be inconvenient but in the best interest of supporting the broader community we have to direct our limited efforts to maintain the latest version.

If you feel this issue / pull request is still relevant and you'd like us to review it, please leave a comment and we'll do our best to get back to you.