Problem with caret position

[nmrtv]

Hi, I have tried to implement autocomplete widget and there is a problem with input's caret positioning. When you assign oninput event and fire it on each character change, sometimes caret jumps out of correct position. This situation occurs when you add a long string, then press and hold backspace key. After deletion input element still have some characters left after the cursor.

[dddomodossola]

Hello @neriusmika , you can try two solutions:

1. setup the parameter parameter update_interval=0, to make a synchronous messaging between browser and remi server,
2. handle a different event, linke keyup, allowing less messaging traffic during typing

[nmrtv]

Tried 1st solution, the problem still remains.

[nmrtv]

Actually the problem is with input element updates. I need to update only sibling dropwdown element and keep input the same. But it seems I can't prevent that. If some child element is changed, then all parent's children are receiving updates. I'm new to Remi and don't know the internals well, maybe I'm doing something wrong. How to prevent updates on input element, but receive them for sibling elements in onchange event handler? Btw, my onchange handler is in input parent widget (but I think that should not cause the problems).

[nmrtv]

@dddomodossola element properties are not synchronized with attributes, maybe we can handle them differently? In such cases updates will not be triggered. I have seen in snabbdom virtual dom library, they have separate dictionaries for properties and attributes. If you don't update attributes, there is no need to replace the element. It should speed up the rendering part too.

[nmrtv]

Solution to my problem is not to store received value to attributes dictionary. But I think that attributes and properties should be updated separately anyway.

[dddomodossola]

@neriusmika yeah of course it could be feasible to update only attributes avoiding to replace the widget. However is not that simple, that is a really sensible part. It's really important to get a solid correspondance between webview and application data.

Just review the problem: you are trying to handle an onchange event emitted by a textinput, in order to make an autocompletion. the problem you are getting is that, during typing caret gets moved in a wrong position. is this correct?

[nmrtv]

it could be feasible to update only attributes avoiding to replace the widget

I mean update properties not attributes. Attributes can be kept the same. In static html, when you write something to input element, it's value property changes, but value attribute remains unchanged. They are different things. Now we don't have the possibility to update properties without changing attributes. And when you change attribute, you introduce expensive dom updates instead of simple property update.

Just review the problem: you are trying to handle an onchange event emitted by a textinput, in order to make an autocompletion. the problem you are getting is that, during typing caret gets moved in a wrong position. is this correct?

Correct. Because when I try to store received value (eg. for later use) in attributes, it updates element immediately and probably misses some events (even with update_interval=0). Actually when you write something to the input element, there is no need to update value attribute, but we must store received value somewhere anyway. And attributes dictionary is not the right place, because we receive value property, not attribute.

[nmrtv]

@dddomodossola I will try to implement some prototype with properties in my fork.

[dddomodossola]

Can you share the script you are getting problem with? Maybe I can review it. I'm probably misunderstanding something.

[nmrtv]

My script is not directly related to that problem. You can read more about properties and attributes here: https://stackoverflow.com/a/6004028 and https://blog.fullstacktraining.com/html-attributes-vs-dom-properties/ We don't always need to update attributes and thus recreate dom elements, but change element (dom object) properties instead. For example you can look at snabbdom virtual dom implementation (used by vue.js etc). It can speed up rendering and in those situations (like changing input value), object will not be recreated, events will not be reassigned, element will not loose focus, etc. So indirectly there will be no such problems with cursor positions because it will stay where it should be without any caret manipulations.

[nmrtv]

Remi in all places where I looked is retrieving properties via sendCallbackParam (eg. param['value'] = document.getElementById('123').value <- it gets value property here, not an attribute) and then in callback handlers setting and updating html attributes (self.set_value(new_value)) which I think is wrong. Probably there should be 4th message type to update only changed properties without recreating the whole element. Of course I can leave such elements unchanged without storing the received value to Remi's Tag attributes dictionary. But it will be just workaround not a complete solution.

[nmrtv]

Btw, you can look at https://github.com/snabbdom/snabbdom/blob/master/src/modules/props.ts the code to update properties is quite simple, but Remi must allow (and track?) property updates in addition to attributes. Probably there should be no difference from a higher level widget code, not every developer should know about those internals. But in situations like reading and updating input value, there is no need to recreate the element.

[dddomodossola]

@neriusmika thank you for the information. I will look into it soon. today I'm busy. however I'm pretty sure that this would not solve the problem. I wi try to make a working example for you.

[dddomodossola]

@neriusmika the problem is this:

• during text editing, the remi server receives the new textinput value (i.e. "some value|");
• in the mean time, further changes happens on the textinput (i.e. "some va|");
• the remi server sends the updated value to the browser (i.e. "some value");
• the caret (that was moved in another position) now gets placed in a wrong position "some va|lue";
• the user continue deleting but the caret position it no more at the end "|lue".

What's the cause? the problem is that, during editing, you are changing (implicitly or explicitly) the value of textinput. The problem would persist also if you don't replace the html element.