Skip to content

fix(iam): enable inline media playback in WKWebView for in-app messages#1656

Open
vitorfinger wants to merge 1 commit into
OneSignal:mainfrom
vitorfinger:fix/enable-inline-media-playback
Open

fix(iam): enable inline media playback in WKWebView for in-app messages#1656
vitorfinger wants to merge 1 commit into
OneSignal:mainfrom
vitorfinger:fix/enable-inline-media-playback

Conversation

@vitorfinger

Copy link
Copy Markdown

Summary

HTML <video> elements inside in-app messages always open in fullscreen native player on iOS, even when playsinline attribute is set. This happens because WKWebViewConfiguration.allowsInlineMediaPlayback defaults to NO on iOS, and it is not being set during WebView initialization in OSInAppMessageView.

This PR adds two configuration lines to the setupWebviewWithMessageHandler: method:

configuration.allowsInlineMediaPlayback = YES;
configuration.mediaTypesRequiringUserActionForPlayback = WKAudiovisualMediaTypeNone;

Problem

When an in-app message contains a <video playsinline> tag:

  1. User taps play
  2. iOS opens the native fullscreen video player on top of the in-app message WebView
  3. A black screen appears while audio plays behind it
  4. The user cannot see the video content

This was confirmed to work correctly on Android (where WebView allows inline playback by default) but fails on all iOS devices regardless of HTML attributes used (playsinline, webkit-playsinline, x-webkit-airplay="deny", etc.).

Root Cause

In OSInAppMessageView.m, the WKWebViewConfiguration is created without setting allowsInlineMediaPlayback. Per Apple's documentation, this property defaults to NO on iPhone. When it is NO, the HTML playsinline attribute is completely ignored by WKWebView.

Changes

  • Set allowsInlineMediaPlayback = YES so HTML5 videos can play inline within in-app messages
  • Set mediaTypesRequiringUserActionForPlayback = WKAudiovisualMediaTypeNone to allow media playback without requiring additional user interaction beyond the initial tap

Testing

Tested with a OneSignal in-app message containing an HTML5 video player:

  • Before fix (iOS): Video opens fullscreen native player, black screen, audio plays behind
  • After fix (iOS): Video plays inline within the in-app message as expected
  • Android: Already works correctly (no changes needed)

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

@nan-li

nan-li commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

@claude review

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

LGTM — two-line WKWebViewConfiguration change to enable inline video playback in in-app messages.

Extended reasoning...

Overview

This PR adds two lines to setupWebviewWithMessageHandler: in OSInAppMessageView.m to configure the WKWebViewConfiguration used for rendering in-app messages: allowsInlineMediaPlayback = YES and mediaTypesRequiringUserActionForPlayback = WKAudiovisualMediaTypeNone. The change addresses an iOS-specific WKWebView default that ignores the HTML playsinline attribute and forces videos into the fullscreen native player.

Security risks

None identified. The change only affects how media is presented within an already-trusted in-app message WebView; it doesn't broaden the content that can be loaded, alter navigation delegation, or change JS message-handler wiring. Autoplay-without-gesture is scoped to the IAM WebView, not the app's other web contexts.

Level of scrutiny

Low. This is a small, mechanical configuration change following documented Apple API behavior, isolated to a single method in the in-app message UI layer. The PR author verified the fix on iOS and confirmed Android behavior was unaffected.

Other factors

Bug hunting found no issues. The mediaTypesRequiringUserActionForPlayback change means IAM video content can auto-play once the user taps, which matches the documented intent and is consistent with how IAMs are triggered (explicit user-driven presentation).

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.

2 participants