Fix iOS camera preview controls issue with inline media playback config#215
Fix iOS camera preview controls issue with inline media playback config#215mayansharma wants to merge 3 commits into
Conversation
|
DeputyDev will no longer review pull requests automatically.To request a review, simply comment #review on your pull request—this will trigger an on-demand review whenever you need it. |
Mrsandeep27
left a comment
There was a problem hiding this comment.
Targeted fix and the two entry points (`WebView.updateUIView` + legacy prewarm path) both call `applyMediaPlaybackConfiguration` — good coverage.
A couple of things to double-check:
1. Default is `false`, meaning this flag has to be explicitly opted into by projects to get the camera-preview behavior. If the bug report (#213?) is that camera previews are currently broken for existing consumers, flipping the default to `true` would restore behavior without requiring every consumer to add the key. If the conservative default is intentional, consider calling that out in the PR description so downstream teams know they need to opt in.
2. buildAppIos.js:685 — addedKeys.add(key) inside the generic property loop is a separate fix from the camera issue. Worth mentioning in the commit message; otherwise a future bisect for a config-processing bug might point here mistakenly.
3. The `inlineMediaPlaybackEnabled` branch writes a literal `false` even when the key exists in the config object — because of the `if (!addedKeys.has("inlineMediaPlaybackEnabled"))` guard, it only fires when truly missing, so that's fine. Just worth an inline comment that this path intentionally runs after the normal config loop so the user's explicit value (if any) wins.
4. Nit: useBaseHook.js dep-array + formatting changes are unrelated drive-by edits. Same comment as on #216 — splitting them out makes each commit reviewable in isolation and keeps `git blame` meaningful.
5. `configuration.allowsAirPlayForMediaPlayback = false` is a behavior change that's worth surfacing separately — the bug report is specifically about camera preview controls, but disabling AirPlay for all video on the page is a broader UX decision. If the camera hot-fix doesn't actually require this, I'd drop it to keep the blast radius small.
Overall looks correct for the reported camera-controls issue.
Added an opt-in iOS config flag,
WEBVIEW_CONFIG.ios.inlineMediaPlaybackEnabled, to control the WKWebView media-playback settings that keep live camera/video previews inline and prevent iOS transport controls from appearing over camera feeds. The default remains false, so existing app behavior is unchanged unless the flag is explicitly enabled.