Range input with dynamic min/max ignores initial value

[leximayfield]

I'm using RmlUi 6.1.

I am attempting to make a slider with a minimum/maximum that is provided by the data model. The RML:

<input type="range" name="max_players" data-value="selected_max_players"
    data-attr-min="min_players" data-attr-max="max_players" step="1" kex-menu-nav />

The code:

template<typename T>
bool BindAddress(Rml::DataModelConstructor &cCtor, std::string_view strName, T *pAddr)
{
    return cCtor.BindFunc(
        Rml::String{strName},                     //
        [pAddr](Rml::Variant &v) { v = *pAddr; }, //
        [pAddr](const Rml::Variant &v) { *pAddr = v.Get<T>(); });
}

// In the binding function...
BindAddress(ctor, "min_players", &this->m_iMinPlayers);
BindAddress(ctor, "max_players", &this->m_iMaxPlayers);
BindAddress(ctor, "selected_max_players", &this->m_iSelectedMaxPlayers);

However, when I open the page with the range input, the minimum and maximum values are correct, but the value itself is set to 2. If I get rid of the data-attr-min/data-attr-max the value is set correctly.

I think I know why this is happening. When DataViewAttribute::Update is called, the attributes are set one at a time. When the code hits InputTypeRange::OnAttributeChange it turns out that the first thing that gets changed is min, which calls this method:

void WidgetSlider::SetMinValue(float _min_value)
{
	if (_min_value != min_value)
	{
		min_value = _min_value;
		SetBarPosition(SetValueInternal(value, false));
	}
}

The default value of a range input is 0, so it gets clamped to 2, which in turn dispatches a EventId::Change event, which sets the actual value to 2. This blows up whatever value was seeded in the model ahead of time.

I believe this is due to the way data views work. It does updates one at a time, instead of all at once, thus if you have multiple views on a single element, and changing one value observed by the data model mutates something else touched by the data model, things go sideways.

It seems like the cromulent thing to do would be to queue all of the changes for a given element, then execute the changes all in one go.

[mikke89]

Hello, and yeah. I think you're on to the right reasons here, in the category of data binding initialization/ordering issues. Just for clarity, what are the initial values you are trying to set here?

It's a bit tricky, this order was actually specified on purpose, see this commit: fb2351d
But I guess this change didn't consider that min/max could actually change the value. Maybe doing the reverse is the right thing to do, consider that min/max will actually change the value? I can't say I remember exactly which situations the commit considered, I can't think of any right now that wouldn't work in the reverse order? We should have some better test cases around this regardless.

This one might be related: #668. Also, ideally we wouldn't even submit a change event in this case: #702 (comment)

I believe this is due to the way data views work. It does updates one at a time, instead of all at once, thus if you have multiple views on a single element, and changing one value observed by the data model mutates something else touched by the data model, things go sideways.

I don't know about this, it's not like we don't consider loops and recursion entirely. And "execute changes all in one go" isn't that helpful, what does execute mean in this case? Usually things happen sequentially, in a defined order, in the end.

[leximayfield]

I don't know about this, it's not like we don't consider loops and recursion entirely. And "execute changes all in one go" isn't that helpful, what does execute mean in this case? Usually things happen sequentially, in a defined order, in the end.

Sorry, I should've been more clear.

What I meant was that the data views were changing the attributes of the range one at a time, instead of batching them up as one set of changed attributes. If batched, then the select would see multiple attributes change at a time and could possibly then choose to say "Okay, I'm only going to fix the value if the value is still out of range after applying the new min, new max and new value." Sending the attribute changes through one at a time means that each attribute change is considered in isolation, preventing the select from doing that sort of reasoning.

However, that's just attributes, and data views can change things other than attributes, so perhaps another approach might be warranted.

[mikke89]

I see, that's a good point. And it's true for attributes, we can in principle batch them up and submit them together. That is pretty unique to attributes though, I don't think this applies generally when mixing other data views.

Looking at the widgets, I don't find any cases where we handle combinations of attributes. Particularly so for the range input. I'd prefer not to introduce more complexity if we can avoid it, and rather try to fix this by submitting them in the right order, if we can. (That's an important if of course). Hm, maybe we could batch attributes if it isn't too complicated.

[leximayfield]

The problem is that if we submit attribute changes one at a time, I can think of a counterexample for each order:

If we submit value before min and max, then this constrains the new value to the pre-change min and max, which will result in hot nonsense.

If we submit value after min and max, then the min and max might constrain the old value and blow away whatever change we had intended.

I think that there is even the potential for trouble if you change min and max one at a time - as the resulting range created from only changing min or max first might be invalid. For example, changing [1, 2] to [4, 8] would cause trouble if you changed the minimum of 1 to 4 first.....that would give you [4, 2] which would be impossible for any value to fulfill.

I can think of two possible routes of fixing this:

• Batch attribute changes made from data views, and change the select element to where it only tries to constrain its values after all attribute changes have been taken care of.
• A way to detect if we're updating the element from a data view that temporarily turns off constraints. Then, we would need a way to run a "constrain" step on each updated element after all views have run their logic. This is a little more vague because I'm not sure what that constrain step would actually look like in practice.

[mikke89]

I'm very curious to see how they deal with this in HTML, surely they must have thought about this too? I have the impression that it is pretty common to set things sequentially there. Is there even another way?

Another alternative is to not actually clamp the value until it is used. Does min/max in HTML even change the value at all?