-
Notifications
You must be signed in to change notification settings - Fork 894
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MonitorHandle
and VideoMode
can become invalid leading to panics
#3258
Labels
S - api
Design and usability
Milestone
Comments
This is true for literally any backend. The same with other resources. It's kind of known problem and we generally. have a bunch of PRs around to not panic in monitor handle. |
daxpedda
changed the title
Windows:
Dec 26, 2023
MonitorHandle
can become invalid leading to panicsMonitorHandle
and VideoMode
can become invalid leading to panics
This was referenced Dec 26, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is an issue in
MonitorHandle
andVideoMode
. In #3303 (comment) @madsmtm has pointed out that on MacOS these handles are not connected toEventLoop
in any way, so they should be fine. We should try and cover all backends and make sure handle method can't and can live after the event loop is exited or otherwise come up with an alternative, e.g. adding a lifetime.VideoMode
toVideoModeHandle
, similar to other types, to represent that they don't just hold static data: RenameVideoMode
toVideoModeHandle
#3328.MonitorHandle
andVideoMode
can become invalid, e.g. a monitor gets disconnected. So all methods should return an error to handle that.EventLoop
so we have to come up with a good solution. This is a similar problem toWindowHandle
is not sound #3317.Cc #971 and #2646.
Original Windows only issue
The
MonitorHandle
on Windows holds aHMONITOR
, which can become invalid if e.g. the monitor is disconnected. Or to be more precise, the Windows documentation recommends to listen toWM_DISPLAYCHANGE
, which can potentially invalidate anyHMONITOR
.All of the
MonitorHandle
methods call theGetMonitorInfo
function and justunwrap()
, which would cause a panic if aHMONITOR
has become invalid.See #3255, which only fixed
MonitorHandle::video_modes()
.The text was updated successfully, but these errors were encountered: