Skip to content

feat(mac/v3): expose mediaTypesRequiringUserActionForPlayback on WKWebView#5513

Open
Eyalm321 wants to merge 1 commit into
wailsapp:masterfrom
Eyalm321:fix/macos-media-playback-options-v3
Open

feat(mac/v3): expose mediaTypesRequiringUserActionForPlayback on WKWebView#5513
Eyalm321 wants to merge 1 commit into
wailsapp:masterfrom
Eyalm321:fix/macos-media-playback-options-v3

Conversation

@Eyalm321
Copy link
Copy Markdown

@Eyalm321 Eyalm321 commented May 27, 2026

Summary

Adds EnableAutoplayWithoutUserAction to MacWebviewPreferences, mapping to WKWebViewConfiguration.mediaTypesRequiringUserActionForPlayback. Without it, there is no way to autoplay HTML5 video/audio in a Wails v3 macOS app — every <video autoplay> is blocked.

Closes #5511. Companion v2 PR: #5512.

Implementation

Mirrors the existing preference-passing pattern (compare TabFocusesLinks, AllowsBackForwardNavigationGestures):

  1. Add EnableAutoplayWithoutUserAction u.Bool to MacWebviewPreferences (webview_window_options.go)
  2. Extend C struct WebviewPreferences with the matching pointer field (webview_window_darwin.go)
  3. Populate it in getWebviewPreferences() via IsSet() + bool2CboolPtr(...)
  4. Apply on WKWebViewConfiguration inside windowNew():
    if (preferences.EnableAutoplayWithoutUserAction != NULL && *preferences.EnableAutoplayWithoutUserAction) {
        config.mediaTypesRequiringUserActionForPlayback = WKAudiovisualMediaTypeNone;
    }

Defaults preserve WebKit's current behaviour (user gesture required) — opt-in only.

iOS already does the equivalent in webview_window_ios.m driven by EnableAutoplayWithoutUserAction in application_options.go; this brings macOS to parity.

Note: allowsInlineMediaPlayback is iOS-only on WKWebViewConfiguration (verified by macos-latest compile failure), so it is intentionally not exposed on macOS — videos always play inline on macOS WKWebView anyway.

Test plan

  • Build on macOS (validated via fork CI on macos-latest / Xcode 16.4)
  • Manual: a v3 app with <video autoplay src="..."> and MacWebviewPreferences{EnableAutoplayWithoutUserAction: u.True} autoplays without a click
  • Regression: unset/false preserves prior behaviour (gesture required)

Summary by CodeRabbit

  • New Features
    • Added a new WebView preference option for macOS enabling media autoplay without requiring explicit user interaction.

Review Change Stack

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 27, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: df7f4a12-1cfc-41cd-87d1-255a60fb8fae

📥 Commits

Reviewing files that changed from the base of the PR and between 0ba4388 and faf027f.

📒 Files selected for processing (2)
  • v3/pkg/application/webview_window_darwin.go
  • v3/pkg/application/webview_window_options.go
🚧 Files skipped from review as they are similar to previous changes (2)
  • v3/pkg/application/webview_window_options.go
  • v3/pkg/application/webview_window_darwin.go

Walkthrough

This PR adds media autoplay support to macOS WebViews by introducing a new EnableAutoplayWithoutUserAction preference. The option flows from the Go MacWebviewPreferences struct through a C bridge into native WebKit configuration, allowing audio and video to play without requiring user interaction.

Changes

macOS WebView media autoplay support

Layer / File(s) Summary
WebView media autoplay option contract
v3/pkg/application/webview_window_options.go
MacWebviewPreferences gains a new EnableAutoplayWithoutUserAction boolean field with documentation mapping it to WebKit's mediaTypesRequiringUserActionForPlayback.
Darwin WebView implementation and wiring
v3/pkg/application/webview_window_darwin.go
C struct WebviewPreferences adds an optional EnableAutoplayWithoutUserAction pointer field; getWebviewPreferences() bridges the Go option into the C struct; windowNew() checks and applies the preference by setting WebKit's config.mediaTypesRequiringUserActionForPlayback to WKAudiovisualMediaTypeNone when enabled.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A hop and a skip through WebKit's delight,
Media now plays without asking a user's consent—
No gestures required for autoplay's flight,
Just bounce to the preference and watch content go bright! 🎬✨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately and specifically describes the main change: exposing a WebKit configuration property for macOS WKWebView.
Description check ✅ Passed The PR description provides a clear summary, implementation details, and test plan, but the standard template checklist items (type of change, test configuration, documentation) are not formally checked.
Linked Issues check ✅ Passed The PR implementation fully addresses the primary objective from issue #5511: exposing mediaTypesRequiringUserActionForPlayback on macOS to enable autoplay without user gestures.
Out of Scope Changes check ✅ Passed All changes are directly aligned with the stated objectives: adding EnableAutoplayWithoutUserAction to MacWebviewPreferences and wiring it through C/Objective-C, with intentional omission of allowsInlineMediaPlayback (iOS-only).
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.12.2)

level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain main module or its selected dependencies"


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@Eyalm321 Eyalm321 force-pushed the fix/macos-media-playback-options-v3 branch from 0ba4388 to c0d1c9e Compare May 27, 2026 21:34
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (3)
.github/workflows/build-macos-media-playback.yml (3)

12-12: 💤 Low value

Job conditions are redundant with branch triggers.

The if: contains(github.ref, 'v2') and if: contains(github.ref, 'v3') conditions are redundant given the workflow only triggers on the two specific branches. If you keep both the branch trigger and job conditions, consider using exact matching like github.ref == 'refs/heads/fix/macos-media-playback-options-v2' instead of substring matching to avoid potential false positives if branch naming changes.

Also applies to: 37-37

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/build-macos-media-playback.yml at line 12, The job-level
conditional "if: contains(github.ref, 'v2')" (and the similar "if:
contains(github.ref, 'v3')") is redundant with the workflow's branch triggers;
remove these contains(...) job conditions from the workflow so the branch
filters defined in the trigger handle selection, or if you must keep a job guard
replace the substring match with an exact ref equality check (e.g., use
"github.ref == 'refs/heads/your-branch-name'" for the specific branch) to avoid
false positives—update the two occurrences of the job-level if conditions
accordingly.

1-54: ⚡ Quick win

Consider security hardening for the workflow.

Static analysis identified several security posture gaps that, while not immediately exploitable, are recommended best practices for GitHub Actions workflows:

  1. Credential persistence (lines 17, 42): The actions/checkout step does not set persist-credentials: false, which means the GitHub token persists in the workspace and could be accessed by subsequent steps.

  2. Overly broad permissions (workflow-level): No explicit permissions: block is defined, so the workflow inherits default repository permissions. Best practice is to grant only the minimum required permissions (likely just contents: read for this build workflow).

  3. Unpinned action references (lines 17, 19, 42, 44): Actions reference tags (@v4) rather than commit SHAs. Pinning to commit hashes prevents supply chain attacks if action repositories are compromised.

For a temporary feature-branch build workflow, these improvements are optional but recommended if this workflow will be promoted to a long-lived or production CI pipeline.

🔒 Security hardening example
 name: Build darwin (media-playback options)
 
+permissions:
+  contents: read
+
 on:
   push:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v4
+        with:
+          persist-credentials: false

For action pinning, you would replace version tags with commit SHAs (example shown for illustration; verify current commits):

-      - uses: actions/checkout@v4
+      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/build-macos-media-playback.yml around lines 1 - 54, Add
minimal workflow security hardening: set persist-credentials: false on both
steps that call actions/checkout@v4 (the checkout steps), add a top-level
permissions block granting only contents: read, and replace the unpinned action
refs (actions/checkout@v4 and actions/setup-go@v4) with pinned commit SHAs (or
another strong pinning mechanism) to avoid supply-chain risks; update the
checkout and setup-go step entries accordingly so the workflow uses
persist-credentials: false, the minimal permissions block, and SHA-pinned action
refs.

3-8: Consider the lifecycle of this workflow after the feature branches merge.

The workflow triggers on specific feature branch names (fix/macos-media-playback-options-v2 and fix/macos-media-playback-options-v3). Once these branches are merged and deleted, this workflow file will remain in the repository but never trigger. Consider either:

  • Using a branch pattern (e.g., fix/macos-media-playback-*) if similar development branches are expected
  • Removing this workflow file after the feature is merged, or
  • Converting this to a reusable workflow that can be triggered manually for testing macOS builds
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/build-macos-media-playback.yml around lines 3 - 8, The
workflow is pinned to two specific branch names
(fix/macos-media-playback-options-v2 and fix/macos-media-playback-options-v3)
which will stop triggering after those branches are merged; update the workflow
trigger in the on: push block to use a branch pattern like
fix/macos-media-playback-* or convert the file into a reusable/workflow_call
workflow or delete the workflow file after the feature is merged so it does not
become a dead workflow entry.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/build-macos-media-playback.yml:
- Line 19: Replace the outdated GitHub Action reference "uses:
actions/setup-go@v4" with the current major "uses: actions/setup-go@v6"
throughout the workflow so the job that configures Go uses the supported
release; search for occurrences of the literal string actions/setup-go@v4 and
update them to actions/setup-go@v6 in the workflow step(s) that set up Go (the
step currently showing uses: actions/setup-go@v4).

---

Nitpick comments:
In @.github/workflows/build-macos-media-playback.yml:
- Line 12: The job-level conditional "if: contains(github.ref, 'v2')" (and the
similar "if: contains(github.ref, 'v3')") is redundant with the workflow's
branch triggers; remove these contains(...) job conditions from the workflow so
the branch filters defined in the trigger handle selection, or if you must keep
a job guard replace the substring match with an exact ref equality check (e.g.,
use "github.ref == 'refs/heads/your-branch-name'" for the specific branch) to
avoid false positives—update the two occurrences of the job-level if conditions
accordingly.
- Around line 1-54: Add minimal workflow security hardening: set
persist-credentials: false on both steps that call actions/checkout@v4 (the
checkout steps), add a top-level permissions block granting only contents: read,
and replace the unpinned action refs (actions/checkout@v4 and
actions/setup-go@v4) with pinned commit SHAs (or another strong pinning
mechanism) to avoid supply-chain risks; update the checkout and setup-go step
entries accordingly so the workflow uses persist-credentials: false, the minimal
permissions block, and SHA-pinned action refs.
- Around line 3-8: The workflow is pinned to two specific branch names
(fix/macos-media-playback-options-v2 and fix/macos-media-playback-options-v3)
which will stop triggering after those branches are merged; update the workflow
trigger in the on: push block to use a branch pattern like
fix/macos-media-playback-* or convert the file into a reusable/workflow_call
workflow or delete the workflow file after the feature is merged so it does not
become a dead workflow entry.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 77eeaeec-a650-4164-a5d1-1778a34edea1

📥 Commits

Reviewing files that changed from the base of the PR and between 6329e9d and 0ba4388.

📒 Files selected for processing (3)
  • .github/workflows/build-macos-media-playback.yml
  • v3/pkg/application/webview_window_darwin.go
  • v3/pkg/application/webview_window_options.go

Comment thread .github/workflows/build-macos-media-playback.yml Outdated
Add EnableAutoplayWithoutUserAction to MacWebviewPreferences, mapping to
WKWebViewConfiguration.mediaTypesRequiringUserActionForPlayback.

Without this option, there is no way to autoplay HTML5 video/audio in
a Wails v3 macOS app — every <video autoplay> is blocked by WebKit's
user-gesture requirement.

Follows the existing pattern used for TabFocusesLinks,
AllowsBackForwardNavigationGestures etc.: u.Bool option, bool* in the C
struct, applied on WKWebViewConfiguration inside windowNew when set.
Defaults preserve current WebKit behaviour (gesture required) — opt-in only.

iOS already does the equivalent in webview_window_ios.m driven by
EnableAutoplayWithoutUserAction in application_options.go; this brings
v3 macOS to parity.

Closes wailsapp#5511
@Eyalm321 Eyalm321 force-pushed the fix/macos-media-playback-options-v3 branch from c0d1c9e to faf027f Compare May 27, 2026 21:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

macOS: expose WKWebViewConfiguration.mediaTypesRequiringUserActionForPlayback and allowsInlineMediaPlayback

1 participant