I just switched from Win7 to Win10 (new install, not upgraded).

When using Classic shell with DF-taskbars the start menu will open behind other windows.
This is not consistent however. The must reliable way to reproduce this is to have a borderless window in focus on the primary monitor and a maximized window on the the secondary monitor
This is not the case, when using either software alone (DF with default menu/classic shell with default taskbar).

I used clean installs of both (naturally on a fresh system).
The secondary monitor has a different aspect ratio than the primary.

A second issue (not sure if related) is that when clicking the start menu multiple times it will open on the primary monitor instead of the secondary. Waiting a short period of time (half a second to a second) will allow the menu to open on the correct sceen again.
This issue is highly reproducable.

I attached a log ("Log All") of me trying to open the startmenu twice. The fist time it opened on the primary, the second time in the background (of a firefox window. The issue is not unique to firefox windows tough)

I also attached both my classic shell and DF settings.

EDIT Aug 2020: For anymone looking at this thread in the future for a solution: There is none up to now, I swapped to Start10 instead of Classic shell, wich works fine with display fusion ¯\_(ツ)_/¯

im sorry for posting this here but has this ever been fixed or is it a setting i missed because im having the same issues and this is the only thing i can find on it.. (been ooking around for a fix for weeks now) its not the end of the world just annoying to deal with since it happens on both my etended desktop monitors (not on my main) i added my settings in attachements. let me know if any other logs are necessary and i hope to get a response soon (if any)

Hi,

I have the exact same problem (Classic Start Menu opening in background).
Here are my findings, I hope this is helpful.
Conditions needed for the bug to happen:
1) any full screen application open (games, video, etc)
2) doesn't matter if borderless or "real full screen" or whatever they're called
3) on primary desktop only - doesn't happen if those full screen windows are located on any extended desktops (I have 4 in total, only affects primary, also not dependent on which one is set to primary)
4) the window is maximized - doesn't happen if it is restored to normal window, even if it triggered the problem when it was maximized, just restoring to regular window makes the start menu work again
5) only affects Classic Start Menu, not the original (no matter which key/click combo I set to invoke Classic or Win style Start menu)

What I have found out in regards to root cause and towards to a possible fix so far:
1) If a trigger app is already open, I can temporarily fix this by setting "Ignore Full Screen Windows" to disabled, then restarting DF, then set it back to enabled. Unfortunately, leaving it disabled is not an option because I don't want the taskbar to always appear in front of full screen windows.
2) Restarting DF after setting it back to enabled brings back the problem, even if I didn't close the trigger app.
3) Opening a trigger app when the option is set to enabled causes the bug to happen.
So this "fix" only works until I don't restart DF or the PC or any of the trigger apps.
I've tried to enable/disable just about every single option related to either full screen, taskbar or start menu or hooks or clicks, this is the only one that makes any difference.

Note: I have tried with both Classic Shell and Open Shell. Behavior is exactly the same.

Hey, thanks for picking this up! It's reproducible with anything fullscreen, tested with games, vlc and now browser too.

here it is. hope it helps.

Sweet, thank you!
Meanwhile I just discovered another detail: if the fullscreen app is in the background (behind some regular window, doesn't matter if it's maximized or not), the issue is not triggered.

I'm not sure what focus means in this context. What I meant in my previous comment is:
There are 2 windows on primary monitor, 1 fullscreen, 1 non-fullscreen (anything else, can be maximized or smaller).
Fullscreen window is on top - issue is triggered.
Fullscreen window is still there but the other window is on top of it - issue is not triggered.
What window is active does not matter - can be either something on the primary or anything on any secondary monitor. The only thing that changes the behavior is which one is on top on the primary monitor.

Awesome, thank you! When you have a nightly/beta build with the fix, I'd be happy to help testing!

Any progress on this please?

Wow. I'm actually using Beta9 just didn't think to try this because there was no mention of anything similar in the changelog. It indeed seems to be working now!