libretro / libretro/RetroArch

MacOS, full screen state is never remembered.

Open
#18,991 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

platform: osx
Dominant language
C
Stars
14.1k
Forks
2.2k
Avg merge
7h 35m
Merged PRs (30d)
51

Description

Is there an existing issue for this?
  • This is a bug in RetroArch frontend
  • I have searched the existing issues
Description

Full screen state is not remembered between application launches.

  • Location of full screen space is not remembered. (I usually have RetroArch taking up the left-most space.)
  • If you have a multi-monitor setup and RetroArch is on a secondary display, it will fall back to the main display.
  • Launching RetroArch from another full screen space will open RetroArch in a small window.
  • Previous, correct behavior It should launch directly into the previous window state.
Expected behavior

RetroArch should remember the space it was occupying and launch directly to it.

Steps to reproduce the bug

...

Version/Commit

ff65ab18

Bisect Results

d90eba9

Present in the nightly version

Yes, this is reproduced in the nightly build

Platform & operating system

macOS Tahoe 26.4.1 (25E253)

Affected Cores

No response

Environment information

No response

Relevant log output

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No source file or test is named. First reproduce the launch behavior on macOS Tahoe with RetroArch on a secondary display or full-screen space, then trace the macOS window-state handling. Done means the previous full-screen space, display, and window state are restored when RetroArch launches.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, macos
Domain
desktop, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.