Property change can be lost when selecting a new element

[pcdavid]

Steps to reproduce:

1. Select an element in the explorer
2. In its Details view, start editing one of its text properties, but do not validate (keep the focus in the text field and do not hit Return).
3. Select another element in the explorer.

Expected: normally, leaving the focus from a text field should perform the corresponding change. This is what happens if you click somewhere else in the details view for example.

Actual behavior: the text change you started to make is lost, and the text property has kepts it original value.

[pcdavid]

This happens because when we change the selection to another element, we compute a new Form representation for the Details view, and immediatly dispose the previous one. If this disposal happens before we treat the EditTextfieldInput (which is highly likely in practice), when we end up trying to handle the EditTextfieldInput there is no matching event processor, so the input is dropped.

[pcdavid]

If the solution we take is to keep the event processor alive a little longer, this can be done (for the case of Forms) by adding a delay in org.eclipse.sirius.web.spring.collaborative.forms.FormEventProcessor.canBeDisposed():

    @Override
    public Flux<Boolean> canBeDisposed() {
        return this.canBeDisposedSink.asFlux().delayElements(Duration.ofSeconds(5));
    }

It seems to work in practice, but feels quite ad hoc and "smelly":

• which delay to use, and why?
• should the apply to all dialects?

It feels like there should be a more reliable way to detect that the event processor is really no longer needed, but I'm not sure as the front (and the network) can have an arbitrary lag and in theory we could receive events targetting an "inactive" event processor at any point in the future.

If we can not to better than adding a delay, we should also send some feedback to the client telling it the the request was dropped (and let it surface the info the end-user if relevant). AFAICT currently we simply log a message on the backend ("No representation event processor found for event") and send a generic "unexpected error" to the client (maybe).

[pcdavid]

I updated the title, as the issue can also happen on combo/select widgets.

[sbegaudeau]

(I'll write here my opinion on the topic to communicate it to everybody even if @pcdavid and I talked about it already)

I don't think that we can solve this problem in 100% of the use cases because of possible network lag but I think that adding a small delay would solve 90% of the occurrences of this problem. The current error message could be replaced by a more specific message indicating that the representation has maybe been disposed. or something like that. I think that we can have this issue with all representations but it's just visible with forms since it's very easy to reproduce it there.

A small variation of the code proposed above could make it work for all representations. By adding something like this:

representationEventProcessor.canBeDisposed().delayElements(Duration.ofSeconds(5))

in EditingContextEventProcessor.acquireRepresentationEventProcessor(Class<T>, IRepresentationConfiguration, IInput)

[pcdavid]

A small variation of the code proposed above could make it work for all representations. By adding something like this:

representationEventProcessor.canBeDisposed().delayElements(Duration.ofSeconds(5))

in EditingContextEventProcessor.acquireRepresentationEventProcessor(Class<T>, IRepresentationConfiguration, IInput)

This corresponds to what I proposed here but I have not tested yet.