Vertical frame drag bug

• Jun 29, 2020 - 23:52
Reported version
3.x-dev
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

See https://musescore.org/en/node/307226 for attachment and demonstration. A copy of the steps is included here:

Include:
1) Vertical Frame
2) System of music with a page break
3) Vertical Frame
4) Another system of music

5) Go to second page and drag the vertical frame's middle node and the frame's height increases tremendously and goes past the entire page...


Comments

Status needs info active

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

Fixed in branch 3.x, commit c20bb49385

_Merge pull request #6308 from worldwideweary/307323-VerticalFrameDragFixWithVerticalScrolling

Fix #307323: Vertical-frame dragging with vertical-scrolling performs…_

Fixed in branch 3.5rc, commit 424aa8ea24

_Merge pull request #6308 from worldwideweary/307323-VerticalFrameDragFixWithVerticalScrolling

Fix #307323: Vertical-frame dragging with vertical-scrolling performs…_

Fix version
3.5.0