If detach inspector palette after factory reset before inspector tour was initiated, then stuck in infinite loop
Reported version
3.2
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
Steps to reproduce:
1. Do factory reset (mscore -F)
2. do all the default starting options
3. complete the welcome tour
4. detach inspector
Result: the inspector tour starts to run, but somehow clicking Next doesn't advance the tour, and we are stuck forever! Closing musescore via File->Quit or pressing the window's [x] is not possible because the tours are modal! Can only forcibly quit the application, such as by pressing Alt->F4.
This is what my screen shot looks like in this state:
Fix version
3.3.0
Comments
Clicking next does not close and reopen the box?
Interestingly, this problem affects my Arch Linux machine (running mate desktop), but not my Windows 10 machine.
Clicking "Next" seems to cause the Tour box to close and reopen, but it is stuck at the first message for that tour but doesn't advance.
Interestingly, I am able to advance the Tour by pressing [Enter] on my keyboard. Somehow clicking doesn't work.
So, I can't test this in debug. I'd step through the code after the mbox->exec() and see which path it takes. Make sure that "i" gets updated to a new value and that it actually sets a new message for mbox. Since it is a strange bug, I'd also make sure that the your isn't getting triggered multiple times or something odd; keep an eye on how it gets to displayTour.
I'm starting to debug. I'm noticing that that bug only happens if I drag the inspector window (by clicking and dragging the "Inspector" title bar) immediately after detaching, before I actually click inside the inspector window (which starts the tour).
Stepping through debugger now, and I find that mbox->exec() start but the problem is it doesn't complete exec(). So it never gets to the subsequent code!
If after using [Enter] to bypass the bug when inspector is detached, if I then go to Help->Tours->"Reset Tours", then I somehow don't experience the bug.
But if I reset the tours and most importantly drag the inspector window first before clicking on it, then I do experience the bug.
I think the bug is a result of the main mscore window not actually being in focus as a result of dragging the inspector window.
googling and I find someone else might have experienced a similar problem with Qt: https://forum.qt.io/topic/95911/hang-observed-at-drag-exec-when-a-qwidg…
Maybe somehow we should disable the tour when detached.
Actually the problem happens on WINDOWS too. The reason I wasn't aware earlier was because I didn't do the crucial step of dragging the inspector window immediately after detaching.
I actually produced a crash on Windows 3.2 release by immediately clicking the close button (after detaching and dragging the inspector window).
Fix typo in issue title.
I made a PR with a simple solution to use MouseButtonPress instead of MouseButtonRelease to initiate Inspector tour: https://github.com/musescore/MuseScore/pull/5195
Fixed in branch master, commit 936a743222
_fix #291646 initiate inspector tour on mouse press
Fixes bug that caused inability to finish the inspector tour if user undocked and dragged the inspector widget before tour was initiated. If the inspector was undocked, then it would interfere with clicking "Next" or "Close" in the tour's popup mbox.
This solution is to start the tour on MouseButtonPress so the tour happens before the main mscore window loses mouse focus._
Fixed in branch master, commit 3326b02ab6
_Merge pull request #5195 from ericfont/291646-inspector-tour-on-mousepress
fix #291646 initiate inspector tour on mouse press_
Automatically closed -- issue fixed for 2 weeks with no activity.