[Sentry: APP-8WS] /transition calls the iOS webkit messageHandlers bridge unguarded on desktop Safari

[mountiny]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.67 / 9.4.68 / 9.4.69
Reproducible in staging?: Needs to be confirmed
Reproducible in production?: Yes — crash is live in production
If this was caught during regression testing, add the test name, ID and link from BrowserStack: N/A — found via Sentry production crash scan
Email or phone of affected tester (no customers): N/A
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause / Sentry production crash scan
Slack conversation (hyperlinked to channel name): N/A

Action Performed:

1. Open Safari on macOS.
2. Sign in to Expensify Classic and start a transition to New Expensify, so the browser lands on https://new.expensify.com/transition.
3. Let the transition page run.

Expected Result:

The transition completes and the user lands in New Expensify. No error.

Actual Result:

An unhandled TypeError fires on the transition page:

TypeError: undefined is not an object (evaluating 'top.webkit.messageHandlers.foregroundToBackground.postMessage')

The page calls the iOS WKWebView message bridge (top.webkit.messageHandlers.foregroundToBackground) without checking that it exists. In a plain desktop browser there is no messageHandlers object, so the property access throws.

Workaround:

Unknown. The transition usually still completes, but the rejection is unhandled and reaches Sentry.

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Sentry details

Sentry issue: https://expensify.sentry.io/issues/APP-8WS

Impact (snapshot at filing, 2026-09-03):

• Users (total since first seen): 25
• Events (total): 653
• Users in scanned releases (9.4.67–9.4.69): 1
• First seen: 2026-04-01
• Last seen: ongoing
• Platform: web (Safari on macOS)
• Affected route: /transition
• Mechanism: auto.browser.global_handlers.onunhandledrejection

Stack trace: the bundle is not symbolicated for this group; Sentry reports only app:///:75:3221 and app:///:75:786414. The thrown expression names the failing call directly.

Suspected cause: the transition page assumes the iOS HybridApp WKWebView bridge is present. Guard the call with a check such as top?.webkit?.messageHandlers?.foregroundToBackground?.postMessage?.(...) before invoking it.

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Krishna2323

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Krishna2323 (External)

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[MelvinBot]

Proposal

This is not an App bug. No code we ship calls webkit.messageHandlers — the error is thrown by third‑party code injected into the page, and our Sentry config isn't filtering it. The fix belongs in the Sentry setup, not on /transition.

What is the root cause of that problem?

foregroundToBackground is not ours. It appears zero times in Expensify/App (source, node_modules, and build artifacts), and org‑wide GitHub code search for foregroundToBackground and messageHandlers returns 0 results. /transition renders PublicScreens.tsx:46 or AuthScreens.tsx:215; neither touches a native bridge, and src/setup/hybridApp/index.ts is intentionally empty on web.

The stack frames prove it. We already documented this exact reasoning for the _classCallCheck noise in #93837: a bare app:/// frame with no basename cannot be App code, because our chunks always ship as app:///<name>-<hash>.bundle.js (rsbuild.common.ts:377) and src/ contains no eval(/new Function( — see classCallCheckNoiseFilter.ts:11-30. APP‑8WS reports app:///:75:3221. That's a URL‑less frame, i.e. injected script.

Why it isn't already filtered: EXTENSION_DENY_URLS only lists real extension schemes. Safari masks or omits the URL of injected scripts, so denyUrls has nothing to match, and createReactNativeRewriteFrames then rewrites whatever is left to app:///.

What changes do you think we should make in order to solve the problem?

Add one entry to the existing ignoreErrors array at setupSentry.ts:60 matching webkit.messageHandlers in the exception value, with a comment explaining that we ship no such bridge on web so any error naming it is injected code.

This also covers the wider family of the same noise (contextMenuMessageHandler, selectedDebugHandler, ReactNativeWebView, etc.) rather than just this one handler name.

Before merging, confirm on 2–3 raw APP‑8WS events that the third_party_code tag is true — thirdPartyErrorFilterIntegration should already be tagging these, and that tag is a one‑click confirmation of everything above.

What alternative solutions did you explore? (Optional)

Alternatives considered and rejected

• Guard the call on /transition. Rejected — there is no call to guard. This was the hypothesis in the issue body and the grep refutes it.
• Add /^webkit-masked-url:\/\//i to EXTENSION_DENY_URLS. Plausible: inboundFiltersIntegration runs before the frame rewrite, so it would still see the original scheme. But if the script was injected via evaluateJavaScript it has no filename at all, and denyUrls cannot match nothing. Worth adding as a complement, not as the primary fix.
• A dedicated noise-filter integration modelled on classCallCheckNoiseFilterIntegration (tag + all-anonymous-frames + message match). More precise, but heavier than the one-line ignoreErrors for a signature App can never legitimately produce.
• Sentry's built-in "browser extensions" inbound filter. Won't help — it matches on the pre-rewrite source URL, which our client has already rewritten to app:/// before the event reaches Relay.

Note on the environment framing: Safari's undefined is not an object (evaluating 'a.b.c') names the expression whose base was undefined. Here that base is top.webkit.messageHandlers.foregroundToBackground — meaning top.webkit.messageHandlers did exist. So these sessions are inside a real WKWebView (an in‑app browser, or iPadOS reported as macOS), not plain desktop Safari. It doesn't change the fix, but the "MacOS: Chrome / Safari" platform checkbox on this issue is probably wrong. The full User-Agent on a raw event would settle it, and may name the injecting app.

Unresolved: which software injects the handler. There is exactly one public reference to this string anywhere — an unrelated project's error-filter list, where it is likewise classified as in-app-browser noise. We don't need to identify it to fix our side.

Related issues

• [Due for payment 2026-09-02] [$250] [Sentry: APP-CN8] Web Cannot call a class as a function on /search #93837 — same class of third‑party Sentry noise, and the source of the app:///-frame reasoning and the filtering pattern used above. Whoever picks this up should read that one first.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/100268) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run · no recording available

[melvin-bot]

@Krishna2323 Huh... This is 4 days overdue. Who can take care of this?

[mountiny]

@Krishna2323 can you analyze the crash and proposal pleasE?

[melvin-bot]

@Krishna2323 Still overdue 6 days?! Let's take care of this!

[Krishna2323]

I'll review this today.