Given an execution that requests an execution on another lifeline, moving that resulting nested execution without any keyboard modifier can result in re-ordering of fragments instead of nudging the nesting (requesting) execution to make space for the nested execution.
Here it can be seen that not only are executions reordered (the nested execution's request message now sent before the requesting execution has started), but the synchronous request message of the parent execution is slanted. It appears that the attempt to nudge the top of the parent execution to accommodate the new position of the request message for the nested execution is only half accomplished. The explorer accurately shows the now incorrect fragment order:
Given an execution that requests an execution on another lifeline, moving that resulting nested execution without any keyboard modifier can result in re-ordering of fragments instead of nudging the nesting (requesting) execution to make space for the nested execution.
Here it can be seen that not only are executions reordered (the nested execution's request message now sent before the requesting execution has started), but the synchronous request message of the parent execution is slanted. It appears that the attempt to nudge the top of the parent execution to accommodate the new position of the request message for the nested execution is only half accomplished. The explorer accurately shows the now incorrect fragment order: