[MU4 Issue] "Edit element" available in context menu but does nothing for large number of elements

[wizofaus]

Describe the bug
The context menu for e.g. frames, lines, articulations etc. has the "Edit element" menu item enabled, but selecting it doesn't appear to do anything - except causing said menu item to then become disabled!

To Reproduce
Steps to reproduce the behavior:

1. Create/open any score
2. Add a frame, line or articulation if necessary
3. Right-click on, or activate context menu for any such element
4. Choose enabled "Edit element" menu command
5. ...nothing changes?

Expected behavior
"Edit element" should be disabled for elements that it doesn't make sense for, esp. if multiple elements are selected. Or perhaps it should do something, but there's no way of knowing what it is...

Screenshots
If applicable, add screenshots to help explain your problem.

Platform information
Windows 10

Additional context
Latest nightly build as of Jun-15, likewise built from latest source

[MarcSabatella]

What it normally does is put the element into "edit mode", which means it can be moved with cursor keys, or it has editable handles, those appear. Some time ago, the edit mode distinction was blurred for some elements like lines, and handles appeared on single-click. I'm not sure if there is any remaining distinction at all. For articulations, it seems currently edit mode changes the step for cursor motion, which doesn't really make sense to me.

[wizofaus]

Sure, I know exactly what edit mode is and have been heavily involved with getting it working in v4 for notes etc. But it's still very problematic, as there's no feedback that you're in such a mode.

In fact for articulations it does change the behaviour of the left/right cursor keys to move the element rather than change the selection.
In v3 for lines/hairpins etc., in edit mode the left/right cursor keys seem to extend the length, vs just moving the whole element. But this doesn't seem to work in v4.
It's also enabled when multiple elements are selected which I'm sure never makes sense.

And I just crashed it...investigating...

[wizofaus]

No luck reproducing the crash, but leaving the stack trace here just in case it helps

Access violation
this was 0x1

MuseScore4.exe!QMapData<enum mu::accessibility::IAccessible::State,bool>::findNode(const mu::accessibility::IAccessible::State & akey) Line 283    C++
     [Inline Frame] MuseScore4.exe!QMap<enum mu::accessibility::IAccessible::State,bool>::value(const mu::accessibility::IAccessible::State &) Line 661    C++
   MuseScore4.exe!mu::ui::AccessibleItem::setState(mu::accessibility::IAccessible::State st, bool arg) Line 239    C++
     MuseScore4.exe!mu::ui::NavigationControl::setActive(bool arg) Line 80    C++
     MuseScore4.exe!mu::ui::NavigationController::onActiveRequested(mu::ui::INavigationSection * sect, mu::ui::INavigationPanel * panel, mu::ui::INavigationControl * ctrl, bool force) Line 1289    C++
     MuseScore4.exe!mu::ui::NavigationController::reg::__l2::<lambda>(mu::ui::INavigationSection * section, mu::ui::INavigationPanel * panel, mu::ui::INavigationControl * control, bool enableHighlight, mu::ui::INavigation::ActivationType activationType) Line 318    C++
     [Inline Frame] MuseScore4.exe!std::_Func_class<void,mu::ui::INavigationSection ,mu::ui::INavigationPanel,mu::ui::INavigationControl ,bool,enum mu::ui::INavigation::ActivationType>::operator()(mu::ui::INavigationSection <_Args_0>, mu::ui::INavigationPanel * <_Args_1>, mu::ui::INavigationControl * <_Args_2>, bool <_Args_3>, mu::ui::INavigation::ActivationType <_Args_4>) Line 968    C++
     MuseScore4.exe!mu::ui::NavigationSection::requestActive(mu::ui::INavigationPanel * panel, mu::ui::INavigationControl * control, bool enableHighlight, mu::ui::INavigation::ActivationType activationType) Line 162    C++
...