sap.m.Select .removeItem resets selection when forceSelection = false, resetOnMissingKey = false

[kvandelden]

OpenUI5 version:
1.78.5

Browser/version (+device/version): Chrome, latest

Any other tested browsers/devices(OK/FAIL):
none others tested

Steps to reproduce the problem:

1. Create a Select Control with 4 items (A,B, C, D)
2. setForceSelection (false) (default)
3. setResetIfMissing(false) (default)
4. Bind control to property with value E.
5. After rendering, the item shown will be blank.
6. removeItem(A)
7. The select control will set the selectedKey binding to value B, when it was and should stay E.

What is the expected result? See 6. The selection isn't reset to B, but remains E

What happens instead? The selectedKey value is reset to the first item of the list.

When the property resetOnMissingKey was added in 1.77, the removeItem API may have not been revised to consider it's value.

Thanks, Kurt

[HerzogIgzorn]

Hello kvandelden,

thank you for submitting this issue. Unfortunately I was not able to reproduce this issue neither with the latest patch level of SAPUI5 1.78, nor with the latest SAPUI5 release version.

In addition to that, your initial description is not 100% correct because the default value for "forceSelection" is true, according to API.

Please provide a working sample that shows the above mentioned behavior.

I used the following code for reproducing the issue: `var oSelect = new sap.m.Select({ forceSelection: false, resetOnMissingKey: false, selectedKey: "E" });

		var oItem = new sap.ui.core.Item({
			key: "A",
			text: "A"
		})

		oSelect.addItem(oItem);
		oSelect.addItem(new sap.ui.core.Item({
			key: "B",
			text: "B"
		}));
		oSelect.addItem(new sap.ui.core.Item({
			key: "C",
			text: "C"
		}));
		oSelect.addItem(new sap.ui.core.Item({
			key: "D",
			text: "D"
		}));
		
		var oButton = new sap.m.Button({
			text: "Remove Item A",
			press: function() {
				oSelect.removeItem(oItem);
			}
		});
		
		oSelect.placeAt('content');
		oButton.placeAt('content');`

Regards Sebastian

[kvandelden]

Sebastian,

I see, my example didn't correctly replicate the problem. The problem appears when the Select control is in a table, and the items and selected key bindings change when scrolling.. However, I am able to provide a simpler js-bin example that illustrates the problem.

https://jsbin.com/qevipet/edit?html,js,console,output

The initial Select items are A, B, C, D are added and selected Key is 'A'.

When I change the selectedKey = 'E' (i.e. when scrolling table rows) then remove item 'A'

the Select control sets B as the selectedKey see the console output of the example.

Thank you for your help, Kurt

[HerzogIgzorn]

Hello Kurt,

thank you for updating the sample accordingly. Regarding the issue inside a table can have several reasons. It depends on the type of table that is being used and if the values are bound to a model or not. Basically it is always recommended to use bound data in tables. This is necessary to ensure that the different scrolling mechanisms work properly.

Unfortunately you were able to reproduce the issue even without any table involved so I forwarded it to the responsible development team. They will contact you directly for further processing. In case of questions, you can refer to the internal incident 2170001575.

Regards Sebastian

[plamenivanov91]

Hello @kvandelden ,

Thanks for the input.

I've investigated the issue and it seems that the Select is working as documented.

The resetOnMissingKey is strictly documented to work with the setSelectedKey public method and not the removeItem. It is well documented here: https://openui5nightly.hana.ondemand.com/api/sap.m.Select#controlProperties

Even though the selection is indirectly changed in the removeItem method, the setSelectedKey is not called.

I am afraid that we can cause some serious regressions if I alter the behavior and make the resetOnMissingKey to be taken into account in removeItem selection behavior as well.

I can discuss this with my Product Owner and colleagues if you insist.

Regards, Plamen Ivanov

[kvandelden]

Hi @plamenivanov91 ,

Using the sap.m.Select control in a sap.ui.table.Table, where the scrolling re-binds the row control values, the Select control becomes unusable if the select items are row / context sensitive.. The current behavior of the Select will modify your data by simply scrolling. after you scroll, the available items of the controls change, (add/ remove items), and consequently the bound selected key gets over written when you simply scroll the table. The jsbin example was to illustrate the problem outside of a table.

I've been able to work around the problem by not calling removeItem, but rather calling removeAggregation..

The introduction of resetOnMissingKey was a result of my original bug calling this modify on scroll behavior out.. The intent of resetOnMissingKey was to fix the the bad behavior when scrolling in a sap.ui.table.Table. I submitted the original ticket through support.sap.com, under Penny Boswell. The follow up was submitted here.

I hope this gets resolved,

Thanks, Kurt

[jdichev]

Hello @kvandelden,

It seems the issue is caused by having a selection of a key "A" in the shared code sample. This key is missing in the case where "A" is removed from the list of options.

Now you might wonder why key is being set on deletion but this is something from the early history of the control which I cannot answer.

Unfortunately this also represents an implicit behaviour that might make a change in the control in this direction backward incompatible and lead to unexpected issues of severity of sort that we had in the past.

We try to always keep this particular control backwards compatible even taking into account these implicit behaviours which might seem strange but since it is used in some really old apps I hope you agree that this makes sense.

I suggest as a solution to also keep track of the selected key value when changing the list of options and make sure resetOnMissingKey will not take effect when changing the list and hope this helps.

Will close this issue and hope you agree also with the provided motivation.

Thanks and best regards, Jordan