Audio continues when a new window is closed

[shakyShane]

Describe the bug
A second window opened at startup will continue to play audio

Steps To Reproduce
Steps to reproduce the behavior, just this:

#![cfg_attr(
    all(not(debug_assertions), target_os = "windows"),
    windows_subsystem = "windows"
)]

fn main() {
    tauri::Builder::default()
        .setup(|app| {
            tauri::WindowBuilder::new(
                app,
                "oops-this-will-close-but-audio-will-continue",
                tauri::WindowUrl::External("https://www.youtube.com/watch?v=JhSZw8fiTLc".parse().unwrap()),
            )
                .always_on_top(true)
                .build()?;
            Ok(())
        })
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

Expected behavior
When I close the second window, I expect the youtube video to stop playing, but instead the audio continues in the background

Screenshots
If applicable, add screenshots to help explain your problem.

Platform and Versions (please complete the following information):
OS: macos
Rustc: 1.65

Would you assign yourself to resolve this bug?

• Yes
• No

Additional context
Add any other context about the problem here.

[shakyShane]

This is a big blocker for me, is there anything I can do to help track down the bug ? 🙏🏻

[FabianLars]

hmm, a really tedious approach would be to go through all the commits that changed something in src/webview/wkwebview and check which commit broke it again 😪 (that's coming from someone with no idea about the macos backend)

For reference here's the old issue: #536 and where it was fixed: #556

[shakyShane]

16d1924 seems to be where the self.navigate("about:blank") was removed

[shakyShane]

Ok re-adding that fixes it, but a bigger issue seems to be the lack of automated test for this to prevent such a bad bug from popping up again in the future. I will have a think of a way to add one :)

[FabianLars]

16d1924 was actually the fix. the about:blank navigation merely resets the process, but doesn't close it which is what we actually want and what #556 implemented back then. But some commit between #556 and today broke it again (it indeed worked correctly, as in no zombie processes, for this timeframe)

[FabianLars]

ah sorry i messed up the PR numbers, #587 was the fix. #556 was only the reset workaround, to stop audio from playing.

[shakyShane]

Ahh, ok fair enough :)

[shakyShane]

at least I can help with a git bisect to find exact commit :)

[shakyShane]

this is the first bad commit 2eba8c9

the commit before this one works correctly