The published web examples panic when opening Print dialog

[Maximetinu]

Bevy version

ATOW, if I'm not mistaken, the web examples are using latest Bevy 0.13

What you did

• Open any Bevy example, like this one: https://bevyengine.org/examples/2D%20Rendering/sprite/
• Open the print dialog of the browser. In Google Chrome, it is File > Print... or pressing Ctrl+P or Cmd+P
• Alternatively, you can call print() in the JS console

What went wrong

The print dialog opens successfully, and even shows a picture of the canvas at the time of opening the dialog:

However, Bevy panics at wasm_example.js:494 panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/web/web_sys/resize_scaling.rs:129:9: created media query doesn't match, 2 != 2

Additional information

• I opened an issue on Winit's side: On web, opening the print dialog (File > Print...) panics rust-windowing/winit#3579 but apparently they can't reproduce on a minimal example
• Besides, it smells like it could be a browser's bug, because it is reproduceable in Google Chrome and Safari, but not in Firefox
• However, I'm opening this issue to Bevy because the asset being hit is a debug_assert! (this one), which shouldn't crash on release builds
• And, AFAIK, Bevy builds the example showcase in Release mode, so it shouldn't be crashing

[james7132]

Potentially related to #12126, according to the winit issue.

[daxpedda]

I previously downgraded this from an assert! to a debug_assert! in Winit because we have encountered issues before. But the fact that this assert is triggered, means that the ScaleFactorChanged event will not function properly.

I'm almost a 100% certain that this is a browser bug, e.g. the code that fails is this:

const mql = window.matchMedia(`(resolution: ${window.devicePixelRatio}dppx)`)
if (!mql.matches)
    throw '`window.devicePixelRatio` doesn\'t match the current `MediaQueryList` state' 

I'm not an expert in the spec, but MediaQueryList should be in sync with the actual current state of any property, otherwise this would introduce a myriad of unintended behavior.

The best way forward is to boil this down to a bug we can actually report to Chrome and Safari, or at least to something we can implement a workaround for in Winit.