mmm looks like the CI is failing potentially because iPhone 15 is old (?)

but thanks @Kudo for working on this! it'd be great to get it in, would unlock a lot on my end :)

Any updates here guys?

Is there any updates here? This fixes a code injection security issue so i think it should be prioritized

Another downstream data point, since this PR fixes two bugs that turn out to be load-bearing simultaneously in the same code path.

Context: Expo SDK 57 DOM components ("use dom") rendered through react-native-webview 13.16.1 (useExpoDOMWebView: false), on Android. This is the same failure as expo/expo#47373, where @Kudo pointed at this PR, the reporter confirmed it resolved the crash, and the issue was then closed as third-party. So this PR is currently the only home for that bug — there is no open Expo-side issue tracking it.

The Android symptom is a hard crash on mount:

Error: Top OS ($$EXPO_DOM_HOST_OS) is not defined. This is a bug in the DOM Component runtime.
  at registerDOMComponent (expo/src/dom/dom-entry.tsx)

because window.ReactNativeWebView.injectedObjectJson is installed asynchronously via evaluateJavascript from onPageStarted, so it can land after the DOM bundle has already been evaluated. Near-certain in dev, where the bundle <script> is parser-blocking, and still reachable in production where it is deferred. iOS is unaffected — it installs the same helper as a document-start WKUserScript.

What that costs downstream: two interlocking workarounds, one per bug this PR fixes.

1. A package patch to expo/src/dom/dom-entry.tsx that polls for injectedObjectJson (16ms, 10s ceiling) and replays the bootstrap, instead of throwing. Turns an intermittent hard crash into a few frames of delay.
2. A deliberately non-empty injectedJavaScriptBeforeContentLoaded. callInjectedJavaScriptBeforeContentLoaded() no-ops on an empty string, and on Android it is the only thing that re-runs injectJavascriptObject() after navigating to the DOM page — i.e. the only way injectedObjectJson ever comes back at all. With an empty string, workaround (1) has nothing to wait for.

That second one is the part worth flagging for prioritisation: it means the injectedJavaScriptBeforeContentLoaded unreliability (#1609, #1099) and the injectedJavaScriptObject bug (#3326) are not independent in practice. Fixing either alone would leave this path broken, which is presumably why the revamped bridge architecture here — addJavascriptInterface always on ReactNativeWebView, making injectedObjectJson() a native @JavascriptInterface available before DOMContentLoaded — is the right shape rather than a targeted patch.

Happy to test this branch against a real Expo SDK 57 app with DOM components on Android and report back, if that would help move the review along.

Downstream security impact evidence for this fix — executed on react-native-webview 13.16.0 (Android 15 emulator)

Context: consumed by a production SDK (stripe/stripe-react-native, peer range *) which feeds injectedJavaScriptObject with {initParams: {appearance, locale, fonts}, initComponentProps: componentProps, appInfo: {applicationId}} — six developer-facing, string-bearing fields.

Vulnerable sink on 13.16.0: RNCWebView.java:279 — injectedObjectJson = function () { return `` + injectedJavaScriptObject + ``; } (raw backtick interpolation of the JSON payload).

Executed chain (all three stages, real device):

1. Code execution at document start — a declarative theme string carrying a template expression:
   appearance.variables.fontFamily = "${console.log('N1-SINK-FIRED')}" →
   [INFO:CONSOLE(3)] "N1-SINK-FIRED" logged before connect.js initialization.

2. Bridge forgery → native action — payload calls
   window.ReactNativeWebView.postMessage(JSON.stringify({type:'openAuthenticatedWebView',data:{url:'https://example.com/phish',id:'x'}}))
   → the downstream SDK's message handler accepted it and opened an unsolicited Chrome Custom Tab at https://example.com inside a payment onboarding flow, zero user interaction:
   ActivityTaskManager: START {act=VIEW dat=https://example.com/...} → topResumedActivity=...CustomTabActivity.

3. Confidentiality — client-secret exfiltration — payload installs an accessor on the page's deferred at document start:
   Object.defineProperty(window,'clientSecretDeferred',{set:function(v){var o=v.resolve.bind(v);v.resolve=function(x){console.log('N1-CHAIN-SECRET:'+x);return o(x);};...}})
   → when the app's fetchClientSecret() result was injected via window.clientSecretDeferred.resolve(<secret>), the attacker wrapper captured it first:
   12:41:55.728 "N1-CHAIN-SECRET:accs_secret__VMPJxOAjK..." — 6 ms ahead of the legitimate consumer's own log of the same value (12:41:55.734).

So the interpolation is not only an escape/robustness issue: any string that reaches injectedJavaScriptObject becomes code execution in the top frame with access to the ReactNativeWebView bridge (native-facing message channel) and to secrets the app delivers to the page.

Same-class sink on iOS in 13.16.0: apple/RNCWebViewImpl.m (return \%@`;`) — static line evidence only (no iOS device run); PR #3958 addresses it.

Full logcat traces available if useful.

+1 on prioritising this. Without addDocumentStartJavaScript, injectedJavaScriptBeforeContentLoaded has no ordering guarantee on Android, so the prop doesn't actually deliver what it promises on half of the supported platforms — and the interpolation sink shown above turns that into a security issue, not just a flaky one.