Fix Firefox fullscreen video on Wayland

[peteruithoven]

Disclaimer. I've gotten a lot of help from GPT, it has:

• Diagnosed the problem (see Can't fullscreen video's from Firefox #2768)
• Written code changes
• Wrote the description below

But I have manually performed the tests. Logging in and out of Wayland each time and once into X11. This was no one shot it took several attempts, adding debug logs in between.

Closes #2768

Summary

This PR improves fullscreen workspace handling in WindowMover to avoid transition timing/focus races observed with Firefox element fullscreen on Wayland.

The fullscreen path now:

• defers workspace move handling to an idle callback,
• coalesces/cancels pending fullscreen move callbacks per-window,
• keeps fullscreen activation non-focused (focus=false) to avoid focus churn,
• avoids META_CURRENT_TIME fallback by using display.get_current_time_roundtrip () when user time is unavailable.

Maximize behavior is unchanged.

What changed

• Updated fullscreen change handling in src/WindowMover.vala to queue movement via Idle.add (...).
• Added pending source tracking and cancellation for fullscreen callbacks.
• Restored explicit non-focused activation for fullscreen transitions:
  • move_window_to_next_ws (window, false)
  • move_window_to_old_ws (window, false)
• Kept existing workspace guard behavior:
  • when exiting fullscreen, if the current workspace contains additional windows, do not force-move back.
• Removed temporary debug diagnostics ([WindowMover] warnings) after validation.

Validation

Wayland (completed)

Verified manually with move-fullscreened-workspace=true:

• Firefox fullscreen enter/exit works.
• Rapid fullscreen toggle spam works.
• Maximize/unmaximize still works.
• Secondary monitor behavior still works.
• Setting io.elementary.desktop.wm.behavior move-fullscreened-workspace off/on behaves correctly.
• Closing app while fullscreen works.
• Additional apps tested: Chromium, Epiphany, Clapper.

Observed warnings (Error in size change accounting. / META_CURRENT_TIME used to choose focus window) can still appear in logs in some transitions, but no user-visible breakage was reproduced in the tested Wayland scenarios.

X11 (completed)

Verified manually in an X11 session with move-fullscreened-workspace=true:

• Firefox fullscreen enter/exit works.
• Rapid fullscreen toggle behavior works.
• Maximize/unmaximize still works.
• Secondary monitor behavior still works.
• No user-visible issues were reproduced in the repeated X11 tests.

Notes

• This change is intentionally scoped to fullscreen workspace move timing/focus behavior.
• No intentional behavior change for maximize workspace movement.

[leolost2605]

Are the changes to the focus behavior really necessary to fix this or is wrapping in idle enough?

[peteruithoven]

AI response:

Thanks for the question. Based on testing and the regression we saw during iteration, idle wrapping alone does not appear sufficient for this issue.

What idle deferral solves is transition ordering: it avoids acting in the middle of Firefox element-fullscreen state changes. That reduced timing races, but we still saw problematic behavior when the fullscreen path performed focused workspace activation.

The key point is that fullscreen transitions are more sensitive to focus churn than maximize transitions. When the fullscreen path used focused activation, we observed logs consistent with unstable activation timing (including META_CURRENT_TIME fallback warnings) and behavior was less reliable. In one local regression, fullscreen callbacks were effectively back on focus=true, and the issue pattern reappeared. Restoring non-focused activation specifically for fullscreen transitions (while keeping maximize behavior unchanged) brought stability back in repeated testing.

So the minimal behavior that has proven stable is:

• fullscreen move handling deferred via idle
• fullscreen workspace activation done non-focused
• maximize path left as-is

This keeps the fix narrowly scoped to fullscreen transitions and avoids changing maximize UX. It also aligns with the original intent of the patch: decouple fullscreen workspace movement from focus-stealing during a fragile transition window.

I'll try to do a A/B test

[danirabbit]

Sorry but using LLMs for coding goes against our contributor guide here: https://docs.elementary.io/contributor-guide/development/generative-ai-policy

And there's also been recent findings that incorporating LLM code could invalidate our entire licensing and copyright. We cannot accept this change

[danirabbit]

@peteruithoven please also consider this a warning. Submitting LLM generated code another time will result in a perma ban. It is that serious

[peteruithoven]

While I understand the hesitation I did check the work. But I'll back off on fixing this issue. Delving into this issue by hand is not something I have time for right now. I won't submit LLM generated code to this project again as long as that policy stands. (I don't want to trigger a discussion here)