View Issue Details

IDProjectCategoryView StatusLast Update
0017642MediaMonkey 5Main Panelpublic2021-07-27 22:24
Reporterrusty Assigned To 
Status closedResolutionreopened 
Product Version5.0 
Target Version5.0.1Fixed in Version5.0.1 
Summary0017642: Spawned dialogs open off-screen if larger than the MM window (and can't be dragged into view in some cases)
DescriptionCurrently (build 2320) MM dialogs open centered on the current MM window. This is problematic in some cases because it results in windows opening:
1) with the titlebar offscreen, so the user is unable to drag the window to a visible position (this occurs in cases where the dialog is taller than the MM window that spawns it). e.g.
1 set MM to run in the upper-left quarter of the screen
2 right-click > Properties
--> Properties dialog appears with the Titlebar and Tabs off the top of the screen so the user can't drag it to a lower position
The only workaround is to either resize the MM Window so that it's at least the height of the Properties dialog, and then re-open Properties OR move the MM Window to e.g. the Lower-left quadrant and re-open.

2) with the left part of the window offscreen even if there's plenty of screen real-estate available (this occurs in cases where the dialog is wider than the MM window that spawns it). e.g.
1 set MM to run in the left half of the screen
2 right-click > Auto-tag
--> Auto-tag window window opens with the left portion offscreen. This is easy to rectify by dragging the window, but it's annoying that this happens _every_ time!

I would suggest that in both cases, if there's space on the screen, the full dialog should display. And if there isn't sufficient space, then the bottom of the dialog (not the top) should display offscreen.
TagsNo tags attached.
Fixed in build2403


related to 0017562 closedpetr Prevent modal dialogs from opening with a size larger than the screen it is on 
related to 0015020 closedpetr Secondary dialogs are hidden (focus issue) 
related to 0016578 closedpetr Menu buttons sometimes stop responding 



2021-03-09 11:14

developer   ~0062303



2021-03-10 02:23

administrator   ~0062334

Verified 2321.


2021-03-10 15:57

administrator   ~0062350

On further testing, there are still issues:
3) Every time a dialog is open (I've been testing with the Properties dialog) it appears in one position and is then redrawn in its expected position. The dialog should just appear in the correct position.

4) Sometimes the dialog appears offscreen and the user who doesn't know how to get out of such a situation will have to force-close MM
note: Winlister shows:
MediaMonkey5, visible at 1,0, size: 1278x604
Edit Properties for multiple files, visible at 32767,32767, size: 588x683


2021-03-10 18:31

developer   ~0062356



2021-03-11 05:55

administrator   ~0062374

Last edited: 2021-03-12 02:49

View 3 revisions

Tested 2322:
3) This problem still occurs the first time the user access a dialog in a session. e.g. run MM and access the Properties dialog
--> user can see it moving from one position to another

4) If the user opens the Properties dialog, it will normally open in the last location in which it opened. Occasionally though, it will open in a different location. This bug is visible at ~62373 see 0:30 to 1:05 (you can see how the Properties dialog opens in one location and then in another).

Neither of these are urgent issues, however, they should be triaged in case they are symptomatic of higher priority issues that should be fixed for 5.0.


2021-03-14 22:30

administrator   ~0062450

5) These issues are likely more severe/pervasive than originally thought as there are also reports of the Properties dialog being misdrawn, and one of the reports indicates that it is occurring more often than not and preventing the user from using the dialog. See:


2021-03-17 13:42

developer   ~0062474

3) fixed


2021-03-17 15:50

developer   ~0062478

FYI I believe this is related to 0017562.


2021-03-17 17:03

developer   ~0062484

Maybe item 5 was related to the same issue


2021-03-18 13:37

administrator   ~0062505

Last edited: 2021-03-19 19:27

View 5 revisions

5) 1001Musik clarified at that the misdrawn dialog only seems to occur for mass edits. Could it be related to 0017669 ?

I can't replicate the misdrawn dialog, but do see that when a mass edit is performed, the dialog is drawn in 2 steps, similarly to what berni captured at except that in my case, the issue rectifies itself. See: (video is with build 2326).

Note also: the 2-step drawing observed for the Properties (mass edit) dialog doesn't occur with any other dialog in MM.


2021-03-19 19:46

administrator   ~0062512

Last edited: 2021-03-19 19:47

View 3 revisions

5) Updated my comments above to provide more information about the supplied video. Also, I've found that the 2-step drawing artifact described above can be made to occur/not occur as follows:

1 Use Properties (mass edit) on a set of 10 files
--> multi-step drawing artifact appears
2 Open File > Add/Rescan files to the library... and press [Cancel]
3 Use Properties (mass edit) on the set of 10 files
--> multi-step drawing artifact is no longer visible
4 Use Auto-tag (mass edit) on the set of 10 files and press [Cancel]
5 Use Properties (mass edit) on the set of 10 files
--> multi-step drawing artifact appears

It seems that whether the artifact occurs is related in some way to the size of a dialog that was opened immediately beforehand?!


2021-03-19 21:32

developer   ~0062513

The Properties 2-step drawing artifact is fixed in 2327.


2021-03-22 21:49

administrator   ~0062535

Verified 2327.


2021-03-22 22:01

administrator   ~0062536

Last edited: 2021-03-23 00:21

View 3 revisions

I've found a variant of the 2-step drawing problem. Each time the user switches between single track edit and mass edit, the dialog is drawn in 2 steps. i.e.:

1 Select a single track, and then right-click Properties, Cancel
2 Select a multiple tracks, and then right-click Properties, Cancel
--> The dialog is drawn in 2 steps
3 Select a single track, and then right-click Properties, Cancel
--> The dialog is drawn in 2 steps

EDIT: It seems that 2-step drawing can also be triggered for other dialogs as follows:
1 Run MM and click Tools > Options (or Play > Sleep, or Play > Equalizer)
--> it opens normally
2 Click Play > Play to > Internal Player Gear --> dialog flashes filling up the screen and then at the expected size!
3 Click Tools > Options
--> it draws in 2 steps (dialog is drawn and a second later the outer margins on the right/bottom are drawn)!
--> at this point, other dialogs also start exhibiting this behavior
- Play > Sleep --> dialog is drawn and a second later the outer margins on the right/bottom are drawn
- Play > Equalizer --> dialog is drawn and a second later the outer margins on the right/bottom are drawn

I don't know if this is just a minor visual issue that can be deferred, OR if it's a trigger that causes failed drawing/UI responses as in the original case, so I'm leaving the target at 5.0 for now. If there's no obvious fix, we can ask users to test out 2327.


2021-03-23 09:10

developer   ~0062542

FYI: User confirmed the fix: with original graphic artifacts.


2021-03-23 15:52

developer   ~0062549

Last edited: 2021-03-23 15:53

View 2 revisions

The two step drawing is caused by sharing the dialog windows to speed up opening dialogs.
i.e. when a dialog like Properties is opened for the first time then it takes longer to show (as the window needs to be created) and on closing the window is just hidden and is re-used for the next dialog to be opened (by it Options, Properties, Sleep or any other dialog).
In addition the not resizeable dialogs like Properties needs to compute its size so that all inserted components can fit the dialog and aren't cut off.
This is mostly done asynchronously though, e.g. in case of Properties there are many Dropdowns with auto-width property that calculates its width once the Dropdowns are filled by data/text etc.

As the two step drawing does not seem to be cause for the original issue reported by users I think it can be pushed as I don't see an easy fix. i.e. it cannot be predicted when the dialog will need a new size (when components are loading/filling asynchronously.

Workaround for 5.0 could be to remember the last used size for each dialog (like we do for resizeable dialogs) and restore this initial size at first (and the subsequent computed size should be the same -- unless e.g. a skin was changed etc.)


2021-05-14 07:31

developer   ~0063199

Please retest in new chromium.


2021-07-27 22:24

developer   ~0064310

This has been fixed and I can't replicate in 2430