Repository navigation
SDK-762 detect WebKit inside in-app iframes - #588
Conversation
…hrome user agent. Chrome on iOS was treated as desktop Chrome, so close controls were bound inside a sandboxed iframe where WebKit drops them.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #588 +/- ##
==========================================
+ Coverage 74.43% 75.32% +0.89%
==========================================
Files 57 57
Lines 2742 2752 +10
Branches 821 822 +1
==========================================
+ Hits 2041 2073 +32
+ Misses 700 639 -61
- Partials 1 40 +39 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Dropping the WebKit probe wiring would leave the close button inside the iframe and this test would fail.
| expect(document.getElementById('iterable-iframe')).toBe(null); | ||
| }); | ||
|
|
||
| it('puts the SDK close button on the parent page when Chrome on iOS cannot bind iframe handlers', async () => { |
There was a problem hiding this comment.
This Jest test forces detection, but no WebKit E2E test exercises the CriOS/non-Safari path.
This test replaces addEventListener with a no-op, directly forcing the detector's blocked result, so it only proves that the parent-control branch works after the detector returns true; it does not verify that a sandboxed WebKit iframe actually produces that result.
Since the fix depends entirely on this engine-specific behavior, should we add a Playwright WebKit regression test with a CriOS/non-Safari user agent and assert that the controls are placed on the parent page?
The Jest probe is stubbed because jsdom runs iframe listeners. This loads the built bundle in WebKit with a CriOS user agent and checks the close button is on the parent page.
3 participants
📝 Summary
🎟️ Jira Ticket: SDK-762
📖 Description
Chrome on iOS identifies as
CriOS, so the Safari user-agent check ingetInAppMessagessent it down the desktop path. The close button and click handlers were bound inside an iframe sandboxed withoutallow-scripts. WebKit does not run those handlers, so the message could not be closed. WithisRequiredToDismissMessageor a full screen layout, no gesture worked. Tapping a templateiterable://dismisslink raises Chrome's "trying to open another application" dialog and does not dismiss.Real Safari still uses the user-agent result, so we do not dispatch a probe event there. Every other browser gets one click dispatched inside the iframe. If the listener does not run, we use the existing Safari path: close button on the parent page, and tap outside still dismisses when
isRequiredToDismissMessageis set.This does not make
iterable://dismissoraction://work on WebKit. Those links stay broken on Safari too. It also does not enable JavaScript inside the message iframe. That remains blocked on backend HTML sanitization (MOB-8729).A docs PR is needed. The in-browser docs say the SDK does not generate a close button in Safari, and they do not mention Chrome on iOS.
🧪 How to test?
Jest:
src/inapp/tests/inapp.test.ts(45 passing, includingwebkitBlocksIframeHandlers).Playwright, published 2.3.2 versus this build, 60 runs (Chrome iOS, Safari iOS, Firefox iOS, Instagram in-app, Android Chrome; default, dismiss required, full screen; SDK close button, template dismiss link, tap outside):
iterable://dismissstill does not dismiss.On an iPhone running iOS 27, against 2.3.2: Chrome shows the app dialog on the template dismiss link in every layout, and the SDK close button does nothing. Safari says JavaScript is not enabled on that same link, and the SDK close button works. The fixed build has not been rechecked on a physical phone yet.
🧾 Changelog
Added under Unreleased in
CHANGELOG.md.📹 Loom recording if applicable
None.
🐞 Github Issues solved
None.
📚 Docs PR if applicable
Not opened yet. The Safari close-button limitation in the in-browser docs is inaccurate and should mention Chrome on iOS. Flagging that a docs PR is required.