mirror of
https://github.com/ElectronNET/Electron.NET.git
synced 2026-02-07 05:37:20 +00:00
Maybe a bug. Electron.Screen.GetPrimaryDisplayAsync(); #1014
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @markatosi on GitHub (Nov 20, 2025).
Steps to Reproduce:
The Screen id is set to -1 so that's probably not correct.
@softworkz commented on GitHub (Nov 20, 2025):
I'm not sure how you got to those results.
The
GetPrimaryDisplayAsync()method is tested by thePrimary_display_has_positive_dimensionstest which is succeeding on all platforms (e.g. https://github.com/ElectronNET/Electron.NET/actions/runs/19494438431)@markatosi commented on GitHub (Nov 20, 2025):
I have no idea either :-) All I did was migrate from electron-sharp to ElectronNet Core.
I did test on MacOS 26.1 and 15.4.
I also tested the bare bones demo app. Doesn't work on that one either.
Is there anything you can recommend that I do to prove that it's not working for me?
@softworkz commented on GitHub (Nov 20, 2025):
Is it like that's the one thing not working and everything else is fine, or is this the first thing your app does and you didn't look any further?
A minimal app which exposes that problem would be helpful to look at what you are doing. (unless your code is open anyway.. :-)
@markatosi commented on GitHub (Nov 20, 2025):
That was the only thing that I noticed wasn't working. Everything else has been fine. Code isn't open but the minimal app i can post
@softworkz commented on GitHub (Nov 20, 2025):
You could check out the develop branch and run dotnet test on that machine, so that we have a baseline (known to be working) for comparison.
@softworkz commented on GitHub (Nov 20, 2025):
That includes the test for the screen.API.
@markatosi commented on GitHub (Nov 20, 2025):
Full error from the minimal app.
@softworkz commented on GitHub (Nov 20, 2025):
This is not the default app startup. How do you do this?
Did you look at the example AspNet app?
Most likely you're just doing this too early?
@markatosi commented on GitHub (Nov 20, 2025):
https://github.com/markatosi?tab=repositories BlazorApp1
The call to the method is via the counter button on the counter.razor
@softworkz commented on GitHub (Nov 20, 2025):
I've cloned it. But I need to get some sleep. Will look at it tomorrow.
@markatosi commented on GitHub (Nov 20, 2025):
I just followed the Blazor setup that is on the home page for this project with the exception of the WASM stuff since this is a blazor server app.
@markatosi commented on GitHub (Nov 20, 2025):
Test Results osx-arm64 Main branch
All tests from Solution.txt
@markatosi commented on GitHub (Nov 20, 2025):
Test Results osx-arm64 develop branch
All tests from Solution Dev.txt
@softworkz commented on GitHub (Nov 20, 2025):
I ran your sample on Windows and there it works fine:
Note that you need to remove the package.json file from the project!
Also see here: https://github.com/ElectronNET/Electron.NET/issues/946
@softworkz commented on GitHub (Nov 20, 2025):
So, what's hapenning? I have no conclusion so far.
You say the screen API was working before on your machine with plain electron? Or with the fork? Did you check the result there? Or was it just that there was no error? Because that's what we are doing. The fork might do otherwise: It might not throw but does it realy give you a result?
@markatosi commented on GitHub (Nov 20, 2025):
Of course it gives a result :-) This is one of the ways I have been using it for almost 2 years
and currently works with electron-sharp a fork of electron net.
@softworkz commented on GitHub (Nov 20, 2025):
I've pushed a change to this PR https://github.com/ElectronNET/Electron.NET/pull/945 to see how the tests work out on macOS 26...
@softworkz commented on GitHub (Nov 20, 2025):
Does it make a change when you remove the
--no-sandbox arg? Did you have the same before?@markatosi commented on GitHub (Nov 20, 2025):
Removing that didn't change anything. I also removed that from the electronNet Test unit config and the tests still fail.
@softworkz commented on GitHub (Nov 20, 2025):
I hid your comment in the migration issue as off-topic. Rather respond here:
This is Electron**.NET**, which means that everything is done the .NET way and there's just a single place to configure things, which is in the .csproj file. Using Visual Studio, you configure everything int he app designer:
see here: https://github.com/ElectronNET/Electron.NET/wiki/Configuration
(otherwise in the .csproj directly)
Docs are almost complete already. Did you take a look at the Wiki?
@softworkz commented on GitHub (Nov 20, 2025):
The tests have succeeded on a macOS 26 runner as well: https://github.com/ElectronNET/Electron.NET/actions/runs/19549035700?pr=945
I don't know much about macOS, so the only idea I have for getting behind this is to try find out what's the difference between execution on those runners and your own system...
@markatosi commented on GitHub (Nov 20, 2025):
I did read that particular documentation but I didn't see how I'm supposed to include arbitrary npm packages that need to be installed. That's what i was talking about when I mentioned reserving judgement. So, when I see some guidance regarding how I'm supposed to add random npm packages via the csproj file I'll be able to better understand how it's supposed to work.
@softworkz commented on GitHub (Nov 20, 2025):
That hasn't changed. Anything custom you do on the npm side needs to be done by using the ElectronHostHook. The main package.json is none of your business because it's only about what Electron.NET needs for its own operation.
But when you have an ElectronHostHook folder with a package.json, that becomes a dependency of the main package.json and in turn, its dependencies will get installed as well.
@softworkz commented on GitHub (Nov 20, 2025):
But thinking about it: using npm for web/client related packages must still be possible. I forgot about that. In your case it's been about electron, but regarding the former case, a package.json might still need to be allowed, so that part needs consideration.
@markatosi commented on GitHub (Nov 20, 2025):
I just created a new blazor app and used the old electron net 23.6.2 and got the following results
@softworkz commented on GitHub (Nov 20, 2025):
Hmmn...
Can you try with earlier pre-release packages. Like
0.1.0-pre.139 and 0.1.0-pre.163
These were before some changes were made to the screen APIs.
@markatosi commented on GitHub (Nov 20, 2025):
Probably a dumb question but how do i get the electron part started with the older release? I'm not getting a electron window only the blazor app is being started.
@softworkz commented on GitHub (Nov 20, 2025):
Ah sorry, these ones probably don't work with Blazor.
Let's try something else. The main problem here is that any exceptions in the host-side code are simply swallowed and we never get to see them. I have pushed a new branch here which should finally reveal what's happening:
https://github.com/softworkz/ElectronNET/tree/test_screen_api
Please run the integration tests suite from this branch and post the output around the failing getPrimaryDisplay call.
Everything that comes from the nodejs side is prefixed with ||
@markatosi commented on GitHub (Nov 20, 2025):
Unfortunately I'm not seeing any nodejs output with this test suite. the results are the same as before just c# errors
@softworkz commented on GitHub (Nov 20, 2025):
Do you see any lines prefixed with || ?
If not, please
@markatosi commented on GitHub (Nov 20, 2025):
When i run the screen tests in the test debugger i'm getting an error with serialization
@softworkz commented on GitHub (Nov 20, 2025):
Ha! That looks like we found the culprit!
@markatosi commented on GitHub (Nov 20, 2025):
Here's the output after enabling the logger
@softworkz commented on GitHub (Nov 20, 2025):
Thanks - but no longer needed. The error is on our side.
I think it's due to the migration to System.Text.Json: The Json.NET serializers have probably ignored the type mismatch for DisplayFrequency while System.Text.Json does not.
@markatosi commented on GitHub (Nov 20, 2025):
I doubt they "ignored" the type mismatch. Newtonsoft just gracefully handled it and no one was the wiser. i still need to use JSON.net in places because it just "works" for some things that seem impossible for system.text.json to do without a lot of hair pulling.
Also, i wouldn't take much stock in github integration tests "passing" at least with respect to macos. I've had plenty of issues with nonsense there. There might be something different about how system.text.json works on .net for mac. Might be worth creating an issue with the dotnet team because it shouldn't work on windows and fail on a mac.
@markatosi commented on GitHub (Nov 20, 2025):
Anyway, I'm happy to run integration testing on my mac whenever you need me to if you want a real test done. Just let me know
@softworkz commented on GitHub (Nov 20, 2025):
I'm quite satisfied with it so far.
I thought it would be obvious, but in case you're wondering why it didn't fail: Because Displayfrequency values are integers there.. 😜
@softworkz commented on GitHub (Nov 20, 2025):
What would be the difference between "ignored" and "gracefully handled"?
@markatosi commented on GitHub (Nov 20, 2025):
I guess converting the floating point or decimal or whatever it is to an integer. Maybe it's an 80/20 type solution :-)
We'll give you a mostly correct answer which is probably good enough most of the time.
@markatosi commented on GitHub (Nov 20, 2025):
Anyway, thanks for all your improvements to ElectronNet. The fact that i can debug the application without having to attach to the asp.net core process separately is awesome.
@softworkz commented on GitHub (Nov 20, 2025):
Hmm, that would be a crazily invalid behavior. But I don't know they're really doing.
Other note: A quick fix for you - until it's fixed here - might be to change your monitor refresh rate to an integral value - LOL 🤣
@markatosi commented on GitHub (Nov 20, 2025):
Now that's funny.
@agracio commented on GitHub (Nov 24, 2025):
In some monitor reviews on YouTube I have seen multiple instances of monitors reporting decimal refresh value on Windows as well.