#--autoplay-policy=no-user-gesture-required

57 messages Β· Page 1 of 1 (latest)

hearty basin
#

Hello, is it possible to configure WebView2 in such a way as to disable the autoplay-policy similarly to how --autoplay-policy=no-user-gesture-required would disable it? I am working on a game and I want the music to begin playing on launch. (The players can disable it in the settings menu.)

I tried adding this to tauri.config.json:
"additionalBrowserArgs": "--autoplay-policy=no-user-gesture-required --disable-features=msWebOOUI,msPdfOOUI,msSmartScreenProtection"
but it didn't work.

Oh, and in case this is relevant, I'm targeting Windows only.

drifting chasm
#

That's exactly how you'd do it actually and it 1000% used to work like this. So either something broke inside webview2, or it's related to your frontend code.

#

Or we broke the additionalBrowserArgs setting but i'd imagine more people would have reported that then.

waxen nexus
#

I can't even get it to stop auto-playing in my Windows 10 tests.

#

Tried both visible and invisible audio elements as well as a visible video. All three play right away with the autoplay HTML attribute.

hearty basin
#

@drifting chasm, I just tried it again to make sure, and it never even launches.

error while running tauri application: Runtime(CreateWebview(WebView2Error(WindowsError(Error { code: 0x8007139F, message: The group or resource is not in the correct state to perform the requested operation. }))))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[1129/173718.029:ERROR:window_impl.cc(120)] Failed to unregister class Chrome_WidgetWin_0. Error = 0
error Command failed with exit code 101.```
#

I also tried using --edge-webview-switches=no-user-gesture-required like @waxen nexus suggested yesterday, but got the same error. 😦

waxen nexus
#

Are you on Windows 10 or 11?

#

And that's the crash I was referring to in #general message.

#

Can you share your HTML/JS where you create the <audio> element?

hearty basin
#

I'm on Windows 10. Here's the JSX (I'm using React) that creates the tag:

<audio ref={(ref) => { this.audioTag = ref; }} loop onPlay={this.setVolume} >
  <source src={coboldCavernMusic} type="audio/mpeg" />
</audio>```
and then this is where it's set to play:

componentDidMount() {
if (this.props.play) {
this.audioTag.play();
}
}

I know it's hideous React 16, but it works otherwise, I am not up to the task rewriting the whole thing from scratch. Just trying to migrate from Electron.
hearty basin
#

By the way the plugin for remembering the window position works beautifully, thank you!

waxen nexus
#

I assume that does the same as document.getElementById("audioTag").play(); which is what I tried and it would play no matter what I did.

hearty basin
#

As to the sound, every time I make a new build it doesn't work initially. I also get this every new build:

waxen nexus
#

If you sign your builds, it should stop that particular error from showing, replaced with one that mentions the publisher is untrusted.

#

Does it happen in tauri dev as well, or just tauri build?

hearty basin
#

The screwed up thing, is if I toggle the sound settings off and on, it works.

#

It works on tauri dev

waxen nexus
#

That explains a lot, I was only trying tauri dev. I'll try tauri build in about 8 hours since I don't have a Windows 10 machine available right now.

hearty basin
#

Thank you!

#

I'm reading up on signing, looks like I need to buy a certificate. Hmm.

hearty basin
#

@waxen nexus, have you had a chance to look at this? 😊

waxen nexus
# hearty basin <@940410398623014932>, have you had a chance to look at this? 😊

Sorry I took so long to get back to you. I couldn't get WebView2 to block autoplay even when changing the Media autoplay setting in Edge. Some settings in Edge are shared but I don't think there's a comprehensive list of which ones.
The setting at the very top of this thread is the correct setting to set the autoplay policy as per this WebView2 feedback issue. I checked the command line at runtime and 1 of the 7 Microsoft Edge WebView2 processes shows what is put in additionalBrowserArgs so I don't think it's broken.
Since you mentioned that it works on dev but not production builds, can you enable the dev tools in production builds by building the app with tauri build --debug? If you're using CI to build then it might be easier to temporarily add the devtools feature flag in Cargo.toml like so: tauri = { version = "1.5", features = ["devtools"] }. I mention CI because that particular SmartScreen warning usually only shows when you're running a program built on another machine.

hearty basin
#

The executable doesn't run at all with these flags. I must be doing something wrong.

#

Here is the full tauri.conf.json, maybe you can see what it is that I'm screwing up:

  "build": {
    "beforeDevCommand": "yarn dev",
    "beforeBuildCommand": "yarn build",
    "devPath": "http://localhost:1420",
    "distDir": "../dist"
  },
  "package": {
    "productName": "MyGame",
    "version": "1.3.0"
  },
  "tauri": {
    "allowlist": {
      "all": false,
      "shell": {
        "all": false,
        "open": true
      }
    },
    "bundle": {
      "active": true,
      "targets": "all",
      "identifier": "mygame-t",
      "icon": [
        "icons/icon.png",
        "icons/icon.ico"
      ],
      "copyright": "Β©  2017 - 2023 Me"
    },
    "security": {
      "csp": null
    },
    "windows": [
      {
        "fullscreen": false,
        "resizable": false,
        "title": "MyGame",
        "width": 1083,
        "height": 920,
        "visible": false,
        "additionalBrowserArgs": "--autoplay-policy=no-user-gesture-required --disable-features=msWebOOUI,msPdfOOUI,msSmartScreenProtection"
      },
      {
        "resizable": false,
        "width": 707,
        "height": 232,
        "decorations": false,
        "url": "splashscreen.html",
        "label": "splashscreen",
        "center": true,
        "additionalBrowserArgs": "--autoplay-policy=no-user-gesture-required --disable-features=msWebOOUI,msPdfOOUI,msSmartScreenProtection"
      }
    ]
  }
}
waxen nexus
#

Can you share the output of tauri info?

hearty basin
#

Where may I find this file?

#

Oh it's a command

#

One moment

waxen nexus
#

Yeah, yarn tauri info would be your equivalent based on what's in your config.

hearty basin
#

[βœ”] Environment
    - OS: Windows 10.0.19045 X64
    βœ” WebView2: 119.0.2151.97
    βœ” MSVC: Visual Studio Community 2022
    βœ” rustc: 1.74.0 (79e9716c9 2023-11-13)
    βœ” cargo: 1.74.0 (ecb9851af 2023-10-18)
    βœ” rustup: 1.26.0 (5af9b9484 2023-04-05)
    βœ” Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 18.16.0
    - yarn: 1.22.17
    - npm: 9.8.1

[-] Packages
    - tauri [RUST]: 1.5.2
    - tauri-build [RUST]: 1.5.0
    - wry [RUST]: 0.24.6
    - tao [RUST]: 0.16.5
    - @tauri-apps/api [NPM]: 1.5.1
    - @tauri-apps/cli [NPM]: 1.5.6

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: React
    - bundler: Vite
Done in 4.89s.```
waxen nexus
#

Well, this one is a head-scratcher because I've got the same:

[βœ”] Environment
    - OS: Windows 10.0.19045 X64
    βœ” WebView2: 119.0.2151.97
    βœ” MSVC: Visual Studio Community 2022
    βœ” rustc: 1.72.0 (5680fa18f 2023-08-23)
    βœ” cargo: 1.72.0 (103a7ff2e 2023-08-15)
    βœ” rustup: 1.26.0 (5af9b9484 2023-04-05)
    βœ” Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 18.17.1
    - pnpm: 8.6.12
    - yarn: 1.22.19
    - npm: 9.6.7

[-] Packages
    - tauri [RUST]: 1.5.2
    - tauri-build [RUST]: 1.5.0
    - wry [RUST]: 0.24.6
    - tao [RUST]: 0.16.5
    - tauri-cli [RUST]: 1.5.6
    - @tauri-apps/api [NPM]: 1.5.1
    - @tauri-apps/cli [NPM]: 1.5.6

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - bundler: Vite
#

It makes no sense that an app would behave so differently based on a flag for the same version...

hearty basin
#

I must have a dumb typo somewhere in my config. An extra space, a comma, something like that.

waxen nexus
#

Would you be able to send me the binary you're running so we can see if it's some weird Windows environment issue?

#

DM, ideally.

hearty basin
#

Let me try something first real quick. I might have bad steamworks

waxen nexus
#

Have you tried to apply the flag to a fresh generated yarn create tauri-app?

#

I don't know why none of this occurred to me earlier.

hearty basin
#

OMG it works!!!

#

Thank you so much for your help!

#

So it was two separate things:

  1. That line needs to go into all windows, not just the main window.
  2. I needed a working steamworks.dll
#

#2 is all on me, but #1 is not really apparent from the docs. Initially I only had it on the main window and sure enough the app didn't launch

waxen nexus
#

Nice! I didn't know it needed to be specified for all windows and would have struggled to figure that out. That should 100% be part of the documentation. I'll go bug the docs guys about that.

hearty basin
#

Once again, thanks for all your help! I very much appreciate the time you spent on this! If you like I'll give you some keys to the game, it's a clicker with "Mostly Bad" reviews (got review-bombed after posting in support of Ukraine and raising prices in Russia and China Β―_(ツ)_/Β― haha)

waxen nexus
#

No problem, I don't need the key but feel free to mention it in #1047149172144492604 if it's built using Tauri.

hearty basin
#

Well, it's been electron since 2018, but once I figure out what to do about the certificate, I'll probably update it on Steam and then I can post.

#

Those things are expensive, lol! A year costs 350 or so, and that's about half the money I make from the game. (It all gets donated, so no personall loss for me, but still.)

waxen nexus
#

I didn't realise Steam had such a lax policy about app signatures. I had always assumed they required apps to be signed.

hearty basin
#

Well, with Electron it's always the same executable, so it may be signed by whoever maintains that.

#

With this, I'm not actually sure what's up, because I haven't tried it yet. Maybe you are right and they'll tell me to get lost until I sign in.

#

Also, I think I can just do a PR to the docs repo. Save you the trouble.

hearty basin
fossil oxide
#

@hearty basin
@waxen nexus
This happens to me too in v2. can you explain what these flags stands for? can I disable it if I develop for desktop only?

hearty basin
# fossil oxide <@348256562378309652> <@940410398623014932> This happens to me too in v2. can ...

Do you have multiple windows? (The default is to just have a main window, but you can manually add others.) If so, then this flag needs to go onto every single one of them. I couldn't find this being documented anywhere, but my PR wasn't accepted because apparently this was self evident to everyone but me. πŸ™‚ That's possibly true, since I don't know rust and this might be a rust convention or something.

fossil oxide
#

@hearty basin
I tried to set these flags on every webview window builder I created, but the windows are still unresponsive