Vertical frame drag bug

Ok. Zero'd in on the fact that this bug isn't reproducible while using the default horizontal scrolling preference, but it only manifests here with vertical scrolling set. At least that's what I've found, so I'll mark this as active again with this additional information. From this, it's probably not OS specific, although the conversation earlier in the "What links here" section gave such an impression.

P.S. It looks like 2.3.2 had this bug also, so no one has fixed it for a long time since it's apparently not of much priority. The workaround of course is to not drag anything but confine yourself to inspector properties and type in numbers.

Ironically, the bug doesn't occur when in "Single Page" view but only in "Page View", and while in Page View, the Box::editDrag code receives an elongated ed.pos.y() value which seems to include all pages for its value.

That is, somehow while in "Page View" with vertical scrolling on, the edit position's y-value of a vertical-frame box is getting computed as one long continuous y-value for some reason.

OK: I've found a fix and so far haven't found a problem:

I've switched using the .pos() data which was giving correct positions for the other modes but not for vertical scrolling + Page View, and made it rather directly use the element's height while adding y's delta value of the edit data. So far, i haven't found any problems and it solved the problem.
Maybe I can sneak this in for 3.5RC or 3.5 afterwards after some more testing. It's just a one liner variation:

within Box::editData() {
_boxHeight = Spatium((ed.element->height() + ed.delta.y()) / spatium());

instead of currently:
_boxHeight = Spatium((ed.pos.y() - abbox().y()) / spatium());

since the ed.pos.y() was giving a huge number with the above mentioned conditions

https://github.com/musescore/MuseScore/pull/6308