Validate scale factor override to prevent panic on invalid values

[omar-y-abdi]

Objective

• Fixes Setting window scale factor override to bad value crashes engine #23141
• Setting Window::scale_factor_override to an invalid value (e.g. 0.0, NaN, negative, infinity, subnormal) crashes the engine with a panic in winit's dpi crate: assertion failed: validate_scale_factor(scale_factor)
• This is especially common with editor tools like bevy_inspector_egui, where changing None to Some(x) defaults to 0.0

Solution

Added scale factor validation at three points in WindowResolution (crates/bevy_window/src/window.rs):

1. set_scale_factor_override() — rejects invalid values with a warn! log and early return, matching the existing check_constraints pattern used for window resize constraints
2. scale_factor() getter — filters out invalid overrides via .filter(), falling back to base_scale_factor(). This is defense-in-depth since WindowResolution derives Reflect, allowing inspector tools to bypass the setter
3. scale_factor_override() getter — same .filter() guard, ensuring all downstream consumers in bevy_winit (window creation, changed_windows system) receive valid values or None

A scale factor is valid when f32::is_normal() && > 0.0, matching winit's own validate_scale_factor criteria.

A private helper is_valid_scale_factor(f32) -> bool centralizes the check across all three call sites.

Testing

• Added 11 unit tests covering:
  • Validation function correctness (zero, NaN, infinity, negative, subnormal, valid values)
  • Setter rejection of each invalid category
  • Setter acceptance of valid values and None (to clear override)
  • Builder method validation
  • Defense-in-depth: direct field write (simulating Reflect bypass) is filtered by getters
• cargo test -p bevy_window — 13 tests pass (11 new + 2 existing)
• cargo clippy -p bevy_window -- -D warnings — clean
• Tested on macOS (arm64)

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[alice-i-cecile]

It's a bit unusual to have validation on the getters, but given that you can mess with these values via reflection / inspectors, I think it's defensible here.

Tests are a bit overkill, but I'm fine with them. They should all be fast to run.

[tbillington]

Having getters that don't return the actual values needs strong justification imo, and a doc comment at absolute minimum

[mockersf]

getters should not not return their value

[omar-y-abdi]

I don't know if my PR still has an issue to resolve or if another PR has solved it already.

If my PR fixes an issue that is still relevant, please feel free to write a review saying what needs to change and i'll commit changes based on your feedback.

[alice-i-cecile]

You should update your PR description :)

[tbillington]

In hindsight I don't know if this actually fixes the original issue. I triggered the panic by setting the value through egui inspector which uses bevy_reflect, so I assume set_scale_factor_override was never actually called, and it was just the fact that the Window had been mutated which triggered bevy to update winit with the new values, completely bypassing set_scale_factor_override.

Were you able replicate the original issue and confirm this PR fixed it?

---

I opened the initial issue more to get inputs from other people on what is the ideal way to solve it and not just to get it fixed asap. I included the reproduction steps of the panic in the issue description, but presented multiple options on how we might solve it. I didn't try to raise a fix PR myself because I wanted to get community consensus on what behaviour we actually want in a situation like this. I also wasn't 100% sure what the correct way to fix it was. It's a niche issue in Bevy today so there was no rush to fix it. But I should have been more explicit about that intention, that's my fault.

Er also you didn't reply to my question about using winit's validation function and just marked it as resolved 😛 . It's usually best to stick to the same logic if possible, but if you have some concerns with it we can help with them. Did you not want to use it for some reason?