Modernflyouts: Bug: ModernFlyouts gets hidden behind other topmost windows and not shown in Lockscreen

Created on 6 Sep 2020  路  18Comments  路  Source: ModernFlyouts-Community/ModernFlyouts

@TharukaN97,

When i use volume up/down , Brightness up/down when watching video in Fullscreen or While playing a game in Fullscreen, Modern Flyouts overlay not appearing top of full screen video / game.

@Sebastian1896,

When the Start Menu is present the flyout gets lost behind. The windows default one is always on top in any moment.

@validatedev,

I cannot see any popup for brightness, caps lock, etc. while the Windows lock screen is activated.

Bug Enhancement Good First Issue Help Wanted High Priority Known issue

Most helpful comment

Yes

All 18 comments

This is a known limitation. It will be fixed in version 1.0 release

That's Awesome. Thanks 馃槉馃憤

I'm sorry you're experiencing this issue. This project originally (i.e. cloned from AudioFlyout by @ADeltaX) had the ability to show itself over every window but was removed temporarily due to some difficulties.

@ADeltaX, could you take care of this issue?

Yes

Well thanks a lot then

Any updates to this? Figured any workaround?

@Cyberdroid1,

Shhhh, KEEP QUIET!

Every one forgot this bug exists. Don't remind them!

I have stopped further progress on this because of these hurdles

  • In order to make the flyout window top most, we have to use an undocumented API (found out, elaborated and demonstrated by @ADeltaX!) which only allows two zones/bands (normal and ultimate [req. UI Access]) for normal apps. Other zones/bands are prohibited to be only used by Microsoft signed applications.

  • As mentioned above, we need a MS signed executable to create the window in a specific band/zone. For that we need to inject our assembly into a MS signed exe (@ADeltaX suggested to use an immersive broker called RuntimeBroker).

  • Injecting our assembly into RuntimeBroker (native process) was not a problem. But loading and executing .NET code inside a native process requires the .NET runtime to be loaded into the same process. This is were the problem begins.

  • .NET Core/.NET 5 doesn't support hosting self-contained runtime onto a native process (but it does that internally somehow). If anyone knows how to host a self-contained .NET runtime onto a native (C++) process, then please help me out.

  • Even though we can host a pre-installed .NET runtime (on the target machine) [i.e. we have to deploy our app as framework-dependent and force users to manually install .NET 5 runtime on their system] onto a native process, self-contained .NET runtime is impossible to be hosted in a native process AFAIK.


@ADeltaX, Could you tell me how to use the UI Access workaround for now?
How could we sign the application with a self signed certificate in order to use UI Access?

As you said in the installation guide of AudioFlyout

AudioFlyoutUA.zip --> doesn't make use of admin privilege but it makes use of UI Access. This will give access to create a top top most window, displayable even in lock screen.
Cons: this requires to be extracted in a protected folder (ex: Program Files), and it should be signed.
Cons: this is test signed, as a code signing certificate is expensive for me to obtain, which means you need to trust the certificate to run it.

@Samuel12321, told me that the application will automatically be signed with a proper certificate while passing through the Store Certification and that the signed certificate will be automatically be installed when the package is being installed.
Since we are using MSIX as the deployment method, we can be 100% sure that the package will be installed on C:\Program Files\WindowsApps\ (a protected folder).

Thus we have fulfilled the two requirements for UI Access.

Would it work?

We could use that until we figure out a better native hosting strategy.

@ShankarBUS, could we we make the app framework dependant and bundle it with the framework using the .appinstaller dependancies?

@ShankarBUS, could we we make the app framework dependant and bundle it with the framework using the .appinstaller dependancies?

You can try this for the beta version. We can add a prompt to install .NET 5 from add a feature setting in control panel.

@Samuel12321,

That's the problem!
.NET 5 runtime is not published as a Framework Package and I read somewhere that they won't in the near future. So, it cant be added as dependency in the APPX package manifest or the appinstaller.

I also heard that MSIX doesn't provide custom actions (like pre-install functions to ensure dependencies).

So, that's that. Only self-contained 馃槩.

@Samuel12321, did I mention your statements correctly? Did I assume anything wrong?

@Cyberdroid1,

You can try this for the beta version. We can add a prompt to install .NET 5 from add a feature setting in control panel.

I don't understand this properly. But let me assume that you meant to provide an option to download the .NET 5 runtime inside the settings window.

Our app wouldn't even start without the runtime!!! How could we show the settings if the wouldn't even start!!

If you meant something different, let me know.

@Samuel12321,

That's the problem!
.NET 5 runtime is not published as a Framework Package and I read somewhere that they won't in the near future. So, it cant be added as dependency in the APPX package manifest or the appinstaller.

Of course, how silly of me to assume Microsoft would have done something logical.馃ぃ

What about Desktop6?

https://github.com/ModernFlyouts-Community/ModernFlyouts/issues/99#issuecomment-742037896

Would it be possible to implement this for the time being when full screen in a UWP app? Essentially automatically disable modernflyouts it when full screen and re-enable it when exit full screen. That way we are at least able to see volume changes even if is the ugly default UI.

WE ARE WORKING ON IT! This is our top priority for now. Most of the work has been done.

I even added the ability to detect full-screen apps. https://github.com/ModernFlyouts-Community/ModernFlyouts/blob/37bb061f8dfb486c4d8f76b1ec483e1e8d8e173d/ModernFlyouts.Core/Interop/NativeMethods.cs#L373

I will add the option to hide the flyout later in v0.10 or so.

Oh, I forgot to notify you all.

This bug is fixed and being worked on in the dev branch of this repository.

The flyout now even shows on top of the lock screen.

Smash the Like button, hit Share and Subscribe to my channel for more updates on this!!!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

toineenzo picture toineenzo  路  4Comments

S1ROZHA picture S1ROZHA  路  4Comments

DanRotaru picture DanRotaru  路  3Comments

privacyguy123 picture privacyguy123  路  3Comments

Dr-Chronosphere picture Dr-Chronosphere  路  4Comments