fix(ios): respect isInspectable option instead of forcing inspectable webviews - #646
Conversation
Beta npm buildThis PR comes from a fork, so beta publish is disabled for security. If you need a beta package, move the branch into this repository first. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🔗 Linked repositories identifiedCodeRabbit considers these linked repositories for cross-repo context during reviews:
📝 WalkthroughWalkthroughThe iOS plugin derives WebView inspectability from bridge configuration when unspecified, stores the setting in ChangesWebView inspectability configuration
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@ios/Sources/InAppBrowserPlugin/WKWebViewController.swift`:
- Around line 2185-2186: Update inheritPopupPresentation and the related
initWebview flow to persist the parent web view’s resolved isInspectable value
and pass it when initializing managed popups, rather than relying on
initWebview’s default of true. Ensure popups preserve the parent’s
inspectability setting on iOS 16.4 and later.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: c1a01d8a-52ad-41c1-81cb-85a0230c5029
📒 Files selected for processing (2)
ios/Sources/InAppBrowserPlugin/InAppBrowserPlugin.swiftios/Sources/InAppBrowserPlugin/WKWebViewController.swift
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
Cap-go/capacitor-updater(manual)
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 2 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
d2edc68 to
8dc02b7
Compare
|
|
@cubic-dev-ai review |
@Swiezu I have started the AI code review. It will take a few minutes to complete. |
2 participants
What
Assigns the
isInspectableoption towebView.isInspectableinWKWebViewController.initWebview,instead of the hardcoded
truethat has been there since 5bba983. When the option is omitted,it now falls back to the app's
webContentsDebuggingEnabledCapacitor config(
bridge.config.isWebDebuggable) rather than a plainfalse.Why
initWebview()parses theisInspectableoption (documented default:false) and passes it allthe way down, then ignores it and forces
webView.isInspectable = true. On iOS 16.4+ that makesevery webview opened with
openWebViewinspectable via Safari Web Inspector in every build,including production/App Store ones — so on a shipped app anyone can attach the inspector to in-app
content such as login or payment pages and read the DOM, cookies and network traffic.
The commented-out block right above it (the
setInspectable:selector) used the parameter; it waslost when that selector was swapped for the
isInspectableproperty and replaced with a literal.Defaulting to
bridge.config.isWebDebuggable(rather thanfalse) keeps existing behaviour in debugbuilds — Capacitor sets
webContentsDebuggingEnabledtotrueonly in DEBUG by default — whilerelease builds stop being inspectable. This is exactly what Capacitor core does for its own webview
in
CapacitorBridge.setupWebDebugging(capacitor/ios), so pages inside the InAppBrowser WebView nowbehave like pages in the main Capacitor WebView. Callers passing
isInspectable: trueexplicitly areunaffected.
Platform parity
WebView.setWebContentsDebuggingEnabledis process-global and Capacitor's Bridge sets it from
webContentsDebuggingEnabled(default: the app'sdebuggable flag). iOS was the gap, because
isInspectableis a per-WKWebView property the plugin has toset itself.
requestGeolocationPermissionFor);this mirrors how the main Capacitor WebView resolves inspectability, including the log-line style.
Testing
Verified on an iOS 18 simulator in a Capacitor 8 app (via a local patch), opening a webview without the
isInspectableoption and readingWKWebView.isInspectableat runtime:In the release build the app's own webview was already correctly not inspectable; only the plugin's
webview stayed inspectable, which this change fixes.
Summary by CodeRabbit