I think we've fixed it, but it's tricky: it's hard to determine when the focused node is removed, as the tree itself doesn't have an event for that so it's not easy to intercept it (and as everything is event driven, it's not doable to add code everywhere to see whether things have changed).
What we've done is cache the focused node before a batch operation starts on the tree and check after the batchjob has been performed whether there's still a focused node. If not, we check if the cached focused node is still in the tree, if not, we use its also cached parent, check that and if either is in the tree, we pick that one instead, otherwise we give up.
This results in the tree keep its scroll position when renaming / removing elements, the focused node is then just moved to its parent.
Could you please try v5.0.5 hotfix build of today, available under 'my account -> 5.0 downloads' and see whether this works for you and if there are glitches we haven't anticipated?
Emmanuel wrote:
FYI, I've noticed that the item that is edited retains its selection state. This help me find it again when I have to scroll down.
True, but that's not usable for solving it, I think: if you remove a field you have the same behavior and that's of course not what you want.
Please let me know if the fix works or if it still is too rigid. I think we might be able to cache a sibling node instead of a parent, but the problem is, if you e.g. remove all the fields of an entity, you want to focus on the parent instead.