ctrl+shift+drag over text frame crashes MuseScore Studio

[sheetsofsound]

Issue type

Crash or freeze

Bug description

ctrl+shift+drag. (Cmnd+Shift+Drag on Mac) over a text frame crashes MS Studio

Steps to reproduce

1. Make a score with a text frame
2. hover mouse over text frame
3. ctrl+shift+drag. MS Studio will crash

Screenshots/Screen recordings

No response

MuseScore Version

OS: Windows 10 Version 2009 or later, Arch.: x86_64, MuseScore Studio version (64-bit): 4.3.2-241630831, revision: github-musescore-musescore-22b46f2

Regression

No

Operating system

windows 11

Additional context

No response

[sheetsofsound]

Diminished based dom7 arpeggios - variation 1.zip

[sheetsofsound]

20240620155000.mp4

[cbjeukendrup]

I've not yet been able to reproduce this. Could you please share the "diagnostic files" from your MuseScore installation? In MuseScore, go to "Diagnostic" > "Save diagnostic files…"; select a save location, and then upload the resulting ZIP file here. Thanks in advance!

[sheetsofsound]

musescore diagnostics.zip

[MarcSabatella]

I can't reproduce either on Linux or Windows, but if I'm reading the diagnostic file correctly, it's suggesting an assert failure here:

https://github.com/musescore/MuseScore/blob/4.3.2/src/engraving/rendering/single/singlelayout.cpp#L225-L230

That's immediately after printing a message about a TBox not handled. I notice the mouse pointer appears to be within or or least close to a text frame. There is also an empty text frame above the one we can see. So maybe the trick to reproducing it will turn out to be positioning the mouse just so during the drag, so that something tries to layout the frame during the act of selection. But so far I haven't succeeded in reproducing the crash no matter how much I fiddle with the mouse position while doing the Shift drag.

BTW, I assume you are using Shift+drag to perform the selection? What if you start with the mouse more clearly below the frame? Or more clearly above? I assume the more usual ways of selecting - eg, click / Shift+click - work OK?

[sheetsofsound]

i'm using ctrl-shift drag and there very well could have been an empty text frame there. I think I filled it in later and when I tried to repro if after filling it in, the crash wasn't happening. I didn't correlate the 2 events but that makes sense.

[MarcSabatella]

You're using Ctrl? That's not how you select - Ctrl+Shift+drag is how you clone an element (such as to drag it to a custom palette). Drag select is just Shift+drag. But, sure enough, that turns out to be the missing piece of the puzzle! I'm finally able to reproduce. It's not actually about drag selecting at all, it's about cloning, and it's specific to text frames.

So to reproduce:

1. Take this or any score with a text frame (vertical frames won't reproduce the problem)
2. Start with the mouse pointer somewhere within the text frame boundary
3. Hold Ctrl+Shift
4. Click in order to initiate a clone-drag

This will crash. Usually it is immediately on the click, but if not, try dragging.

It's not a recent regression - same result going back to 4.0 - and also in 3.6.2, although there I don't see the crash until I actually commence dragging.

[sheetsofsound]

the difference is that adding the CTRL allows you to select it even through other elements like frames that are there. Maybe that's not a deliberate thing but that's why I use ctrl

[MarcSabatella]

No, I think you might be confused, or your memory is playing tricks on you. Ctrl+Shift has nothing to do with selecting - again, it’s about cloning. If you start a Ctrl+Shift+drag operation when your mouse pointer is directly over an object, it commences a clone of that object. If you start the Ctrl+Shift+drag operation when the mouse pointer is not directly over an option, it does happen to do a select, but the Ctrl is simply ignored. At least it’s supposed to be as far as I know, and I can’t find any situation where it has any effect when used in that way. Frames are ignored when drag-selecting through them, Ctrl or no Ctrl.

[sheetsofsound]

No, i'm not confused. Here's an example. First attempt is shift drag. It selects the whole document and moves it. Second try is ctrl-shift drag.

20240620201544.mp4

[MarcSabatella]

Oh, I see, you've run into another bug - a harmless one. As far as I know, it was never intended that Ctrl have the side effect of allowing you to start a drag-select while your cursor is within a frame. Again, in all cases, Ctrl+Shift+drag is supposed to start a clone operation. It's just that currently, cloning frames isn't supported, so that operation has to be refused, and it just happens to be the case that attempting this unsupported operation currently results in a behavior that turns out to sometimes be convenient. Probably it should simply ignore the Ctrl like it does if you start in any empty space, and do exactly the same as plain Shift+drag. But it seems a harmless enough bug as it does allow to you start your drag select within a frame, so I won't report that bug if you don't :-)

Anyhow, bottom line: Ctrl+Shift+drag with your cursor starting off within a frame was never meant to be supported in any special way, and definitely is not intended to be a method for selecting things. To drag-select, you are supposed to start with your cursor in an empty area of the score, then simply use Shift+drag.

Clearly, Ctrl+Shift+drag of a text frame shouldn't crash the program, though. So regardless of what else the operation does or does not do, the crash should be fixed.