feat(window): add command to set fullscreen on specific monitor

[Oscar3170]

Add a new command to the window core plugin set_fullscreen_on_monitor which receives a position and sets the window as fullscreen on the monitor that contains the position.

Since tao already exposes a way to specify the monitor for the fullscreen function, it was only necessary to expose this parameter in the tauri-runtime-wry and window plugin.

Since monitor names are not unique the new function needs the monitor's position to know which monitor we actually want.

This is the most useful on wayland systems, since the window can't move itself any other way, and this at least gives an option for applications that need to be fullscreen.

Workaround for issues: #14019 and #7376.

[Oscar3170]

The naming and function parameters could cause confusion, since the other set_fullscreen functions can set the fullscreen state on or off, while this new function only sets fullscreen on.

I figured it would be best to leave the job of turning off the fullscreen state to the regular set_fullscreen function, since the monitor is irrelevant in this case.

Be free to give feedback on if I should change the name or add a bool parameter to the function.

[Qodo-Free-For-OSS]

Hi, SetFullscreenOnMonitor does nothing when monitor_from_point returns None, but the command still resolves successfully, so callers cannot detect failure or provide feedback.

Severity: action required | Category: correctness

How to fix: Return error when monitor missing

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

set_fullscreen_on_monitor currently succeeds even when no monitor is found for the provided point, causing a silent no-op.

Issue Context

The handler branches on if let Some(monitor) and otherwise does nothing. Since the dispatch path returns Ok(()) when the message is delivered, callers can't detect failure.

Fix Focus Areas

• crates/tauri-runtime-wry/src/lib.rs[3433-3437]

Proposed fix

Change the handler to emit a warning and/or surface a failure back to the caller. Options:

• Convert this message to a request/response pattern (like other getters) returning Result<()> through a channel, and return Err(Error::FailedToGetMonitor) when monitor_from_point is None.
• If you want to keep fire-and-forget semantics, at minimum log a warning when monitor_from_point is None so the failure is observable.

We noticed a couple of other issues in this PR as well - happy to share if helpful.

---

Qodo code review - free for open-source.