[$250] Android - Accounting - Unable to connect to Xero

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.26-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176909/test-cases/41237449
Email or phone of affected tester (no customers): fischer9966+070226acc@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Google Pixel 5 / Android 14
App Component: Workspace Settings

Action Performed:

1. Open Expensify App on Android
2. Login with new gmail account
3. Create new workspace
4. Go to Workspace settings > More feature > Accounting > Set to ON
5. Go to Workspace settings > Accounting
6. Tap to Xero
7. Set 2FA
8. Follow the Xero connection flow

Expected Result:

User can successfully establish a connection to Xero

Actual Result:

Unable to connect to Xero. A blank page opens instead of the connection flow.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7197274_1782980286826.Android-Unable-Xero-connection.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7197274

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072668965375152559
• Upwork Job ID: 2072668965375152559
• Last Price Increase: 2026-07-02

Issue Owner

Current Issue Owner: @KJ21-ENG

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/20f349d692f6619d24f20210b55e42a0a57ba6559d604cc5cf58b3fd02712a45

[MelvinBot]

Proposal

ℹ️ Medium confidence. The client-side mechanism below is confirmed from code; the exact point in the OAuth redirect chain where auth is lost is inferred (it depends on OldDot/Web-Expensify behavior I can't see from this repo). Very likely the same root cause as the open QBO report Expensify/App#94142 ("QBO – Can't connect on Android app", blank tab) — both are accounting-integration connect flows that render blank only on the native app.

What is the root cause of that problem?

On the native app, the Xero connect flow does not open the setup link in the system browser like web does — it renders the OldDot setup URL inside an in-app incognito WebView and manually injects the session as a single request header. That auth does not survive the OldDot → Xero OAuth redirect chain, so an unauthenticated/empty response renders as a blank page.

• Web opens the link in a real browser tab (full session cookies) via openLink(...) — ConnectToXeroFlow/index.tsx:25-27 → works.
• Native navigates to a setup screen that mounts an in-app WebView instead — ConnectToXeroFlow/index.native.tsx:16-23 → XeroSetupPage/index.native.tsx:13-19.
• The WebView is incognito (ephemeral cookie jar) and only sets Cookie: authToken=${authToken} on the initial request — AccountingSetupWebViewPage.tsx:55-66. The manually-injected header is not replayed when ConnectPolicyToXero redirects into the Xero OAuth flow, so the session is dropped mid-redirect.

Supporting detail & data flow

• The loaded URL is https://www.expensify.com/api/ConnectPolicyToXero?policyID=... (production; native always uses prod config), built by getXeroSetupLink with no auth in the query string — Xero.ts:18-22, ApiUtils.ts:49-52.
• Contributing factor specific to these repro steps: both this issue and Expensify/App#94142 start with a freshly created account/workspace. authToken is read as session?.authToken ?? null (AccountingSetupWebViewPage.tsx:31); if the session isn't fully populated when the WebView mounts, it sends Cookie: authToken=null and the very first request is already unauthenticated.
• QBO uses the identical AccountingSetupWebViewPage mechanism, which is why Expensify/App#94142 shows the same blank-page symptom.
• Cannot fully confirm from this repo: the redirect/response behavior of ConnectPolicyToXero lives in Web-Expensify/OldDot. Production logs for api/ConnectPolicyToXero from Android user-agents would confirm whether the request arrives authenticated and what status/redirect it returns.

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

Make the native WebView carry the session through the whole redirect chain rather than relying on a one-shot request header:

1. Write the session cookie into the native WebView cookie store for the .expensify.com domain before loading (e.g. @react-native-cookies/cookies) so it is replayed on the OAuth redirects, and drop/reconsider incognito (it forces an ephemeral cookie jar). — AccountingSetupWebViewPage.tsx:55-66
2. Guard the load until session.authToken is truthy, so a brand-new-account race can't fire an unauthenticated first request (show the existing loading indicator until then). — AccountingSetupWebViewPage.tsx:31

Because this component is shared, one fix here covers Xero and QBO (Expensify/App#94142).

What alternative solutions did you explore? (Optional)

Open the setup link in the system browser on native too (matching web via Linking/openLink). Simpler, but the in-app WebView pattern exists specifically to hand the app's session to OldDot — the system browser may not be signed in — so fixing the WebView's cookie handling is the more reliable direction.

🔗 Related issue

• Expensify/App#94142 — "[$250] QBO - Can't connect on Android app" (open, External): same blank-page-on-native symptom, same shared component. Likely resolved by the same fix.

---

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

[kitvasyl]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Android, connecting a workspace to Xero after enabling 2FA opens a blank page instead of continuing the Xero authorization flow.

What is the root cause of that problem?

In src/components/ConnectToXeroFlow/index.native.tsx, the effect that opens the authenticated Xero WebView runs only on mount. When is2FAEnabled changes from false to true after setup, that transition is ignored. DynamicSuccessPage then uses openLink(getXeroSetupLink(...)), which does not include the authToken cookie supplied by the native WebView, so the connection endpoint cannot initialize correctly and displays a blank page.

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

Update ConnectToXeroFlow to react when is2FAEnabled becomes true and open its WebView at that point. For the native Xero 2FA completion path in src/pages/settings/Security/TwoFactorAuth/DynamicSuccessPage.tsx, return to the existing Xero flow instead of opening the setup URL through openLink. This keeps the request inside the WebView that supplies Cookie: authToken=... and allows the connection flow to continue after 2FA.

What alternative solutions did you explore? (Optional)

Passing authentication through the generic openLink path was considered, but reusing the existing authenticated native WebView is smaller and avoids duplicating its platform-specific session handling.

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Android, following the Xero connection flow from Workspace > Accounting > Xero, after setting up 2FA and tapping the success page's action button, a blank page opens instead of the in-app WebView that loads the Xero OldDot setup link. Expected: the Xero connection flow (in-app WebView at POLICY_ACCOUNTING_XERO_SETUP) loads and the user can complete the connection.

What is the root cause of that problem?

In src/pages/settings/Security/TwoFactorAuth/DynamicSuccessPage.tsx:76-87, the onButtonPress handler for the post-2FA success screen calls goBack() (which invokes quitAndNavigateBack(dynamicBackPath)) and then synchronously calls Navigation.navigate(ROUTES.POLICY_ACCOUNTING_XERO_SETUP.getRoute(policyID)). On native, dismissing the 2FA RHP and immediately dispatching a new navigate races the in-flight goBack transition — the XERO_SETUP navigation is issued mid-transition and dropped/no-ops, so the RHP either closes entirely or lands on a screen that never mounts XeroSetupPage, producing the blank page. The USD bank flow above (lines 44-55) already handles the same class of race with afterTransition, but the Xero branch does not.

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

1. src/pages/settings/Security/TwoFactorAuth/DynamicSuccessPage.tsx:76-89 — Defer the Xero navigate until after the goBack transition completes: on native, pass an afterTransition callback to Navigation.goBack(dynamicBackPath, {afterTransition: () => Navigation.navigate(ROUTES.POLICY_ACCOUNTING_XERO_SETUP.getRoute(policyID))}) (mirroring the USD bank pattern at lines 45-54), or restructure so the forward navigate is scheduled after the modal-dismiss transition resolves rather than fired synchronously.
2. On web, keep openLink(...) inline in the same click gesture (popup-blocker constraint) — only the native branch needs the deferral.
3. Verify by running the repro on Android: after 2FA success button press, confirm XeroSetupPage/index.native.tsx mounts and AccountingSetupWebViewPage loads getXeroSetupLink(policyID) in the WebView.
4. Sanity-check the same DynamicSuccessPage handler for other integrations that may later reuse dynamicForwardPath and apply the same fix.

What alternative solutions did you explore? (Optional)

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 13:17:43 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Android, tapping Xero in Workspace > Accounting and going through the connection flow lands the user on a blank white page instead of the Xero login screen. The connection can never be completed. This is Android App only — the same flow works on iOS and on web.

What is the root cause of that problem?

The Xero connect flow renders inside an in-app WebView. Tapping Xero mounts ConnectToXeroFlow (src/components/ConnectToXeroFlow/index.native.tsx), which navigates to XeroSetupPage (src/pages/workspace/accounting/xero/XeroSetupPage/index.native.tsx), which renders AccountingSetupWebViewPage (src/pages/workspace/accounting/AccountingSetupWebViewPage.tsx). That page loads the OldDot Xero setup link in a single <WebView>.

The WebView props themselves are fine — incognito is set (the documented Android white-page workaround), and the URL/auth cookie match the QBO flow that works. What's missing is popup handling. Xero's OAuth step opens a new window (window.open / target=_blank), and on Android react-native-webview defaults setSupportMultipleWindows to true. When the page tries to open that second window, Android has nowhere to render it because AccountingSetupWebViewPage has no onOpenWindow handler, so you get a blank frame with no content.

The proof that this is the gap is right next to it: ConnectToHRFlow/index.native.tsx is the other in-app OAuth flow, and it handles exactly this case — it wires up onOpenWindow (line ~127), captures the target URL into state, and renders a second popup WebView that shares cookies with the first (it deliberately drops incognito on that popup so the OAuth cookies carry over). AccountingSetupWebViewPage does none of that.

One caveat I want to be upfront about, since this is a blank-page/WebView bug and those are only ~50% diagnosable from a code read: if the blank page is actually Google/Xero refusing to render OAuth inside an embedded WebView (disallowed_useragent), or the OldDot ConnectPolicyToXero page itself rendering empty, that content is served by OldDot/Web-Expensify and can't be fixed from this repo. That needs an Android repro with WebView console/network logs to separate the two. The onOpenWindow gap is the one actionable in-App cause and it matches the HR-flow precedent, so it's the fix I'd start with.

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

Add popup handling to AccountingSetupWebViewPage, mirroring ConnectToHRFlow/index.native.tsx. Give it an onOpenWindow handler that stores event.nativeEvent.targetUrl in state and renders a second WebView (without incognito, so cookies are shared) for that popup URL. Doing it here rather than in the Xero page means QBO and any other accounting connection routed through this component get the same fix for free.

const [popupUrl, setPopupUrl] = useState<string | null>(null);
const handleOpenWindow = (e) => setPopupUrl(e.nativeEvent.targetUrl);
// on the main WebView: onOpenWindow={handleOpenWindow}
// then render a second <WebView source={{uri: popupUrl}} /> when popupUrl is set

There are no Android tests exercising an onOpenWindow/popup path for the accounting WebView today, so I'd add one alongside the existing Xero tests. Because this is a WebView rendering bug, I'd confirm the fix on a real Android build before treating it as done.

What alternative solutions did you explore? (Optional)

I looked at whether the migration in #92512 switched the flow from an external browser to a WebView and broke it — it didn't; the native Xero flow already used an in-app WebView before that PR, which only moved it from a <Modal> into an RHP screen. I also checked for a missing prop or auth mismatch versus the working company-cards flow and found the props identical, which is what pointed me to popup handling as the real difference.

[ahmdshrif]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Android, tapping "Connect to Xero" in Workspace → Accounting fails with "Unable to connect to Xero" — the Xero OAuth setup flow never authenticates the user, so the connection cannot be established.

What is the root cause of that problem?

The Xero setup is loaded in an in-app WebView (XeroSetupPage/index.native.tsx → AccountingSetupWebViewPage). The user's authToken is passed only as a one-shot request header on the initial source load:

App/src/pages/workspace/accounting/AccountingSetupWebViewPage.tsx

Lines 55 to 66 in a9e6aed

	<WebView
	source={{
	uri,
	headers: {
	Cookie: `authToken=${authToken}`,
	},
	}}
	userAgent={getUAForWebView()}
	incognito // 'incognito' prop required for Android, issue here https://github.com/react-native-webview/react-native-webview/issues/1352
	startInLoadingState
	renderLoading={renderLoading}
	/>

source={{ uri, headers: { Cookie: `authToken=${authToken}` } }}
userAgent={getUAForWebView()}
incognito // required for Android

On Android the incognito prop uses an ephemeral cookie store and the headers.Cookie value is applied to the first request only. The Xero setup command (getXeroSetupLink, shouldSkipWebProxy: true) redirects out to Xero's OAuth screen and back to the Expensify callback; that return request is a fresh navigation, so the authToken cookie is no longer attached and the callback is treated as unauthenticated → "Unable to connect to Xero." Same command builder as QBO:

App/src/libs/actions/connections/Xero.ts

Lines 18 to 23 in a9e6aed

	const getXeroSetupLink = (policyID: string) => {
	const params: ConnectPolicyToAccountingIntegrationParams = {policyID};
	const commandURL = getCommandURL({command: READ_COMMANDS.CONNECT_POLICY_TO_XERO, shouldSkipWebProxy: true});
	return commandURL + new URLSearchParams(params).toString();
	};

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

Persist the auth cookie for the whole redirect chain instead of relying on a single-request header. In AccountingSetupWebViewPage.tsx, before rendering the WebView, set a real cookie on the API domain via ``@react-native-cookies/cookies `CookieManager.set(...)` and enable `thirdPartyCookiesEnabled` (and `sharedCookiesEnabled` for iOS), so the token survives the Xero OAuth round-trip:

App/src/pages/workspace/accounting/AccountingSetupWebViewPage.tsx

Lines 55 to 66 in a9e6aed

	<WebView
	source={{
	uri,
	headers: {
	Cookie: `authToken=${authToken}`,
	},
	}}
	userAgent={getUAForWebView()}
	incognito // 'incognito' prop required for Android, issue here https://github.com/react-native-webview/react-native-webview/issues/1352
	startInLoadingState
	renderLoading={renderLoading}
	/>

Since this component is shared, verify the same change does not regress the QBO setup flow (QuickbooksOnlineSetupPage/index.native.tsx), which uses the identical WebView path.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 13:23:21 UTC.

Proposal

What is the root cause of that problem?

On Android, the Xero connect flow routes into the native Xero setup screen after 2FA, and that screen passes getXeroSetupLink(policyID) directly into AccountingSetupWebViewPage.

App/src/components/ConnectToXeroFlow/index.native.tsx

Lines 16 to 22 in a9e6aed

	useEffect(() => {
	if (!is2FAEnabled) {
	setIsRequire2FAModalOpen(true);
	return;
	}
	Navigation.navigate(ROUTES.POLICY_ACCOUNTING_XERO_SETUP.getRoute(policyID));
	// eslint-disable-next-line react-hooks/exhaustive-deps

App/src/pages/settings/Security/TwoFactorAuth/DynamicSuccessPage.tsx

Lines 76 to 87 in a9e6aed

	goBack();
	if (dynamicForwardPath) {
	const policyID = route.params?.policyID;
	if (policyID) {
	// Open Xero setup the same way ConnectToXeroFlow does per platform: on web open the link inline in a
	// new browser tab (within this button's gesture), on native navigate to the in-app WebView setup
	// screen. Calling openLink on native would open the external browser instead of the WebView.
	if (getPlatform() === CONST.PLATFORM.WEB) {
	openLink(getXeroSetupLink(policyID), environmentURL);
	} else {
	Navigation.navigate(ROUTES.POLICY_ACCOUNTING_XERO_SETUP.getRoute(policyID));
	}

App/src/pages/workspace/accounting/xero/XeroSetupPage/index.native.tsx

Lines 13 to 18 in a9e6aed

	return (
	<AccountingSetupWebViewPage
	uri={getXeroSetupLink(policyID)}
	testID="XeroSetupPage"
	context="XeroSetupPage"
	/>

That setup link is the OldDot ConnectPolicyToXero API command URL, not an already-authenticated browser/OAuth URL.

App/src/libs/actions/connections/Xero.ts

Lines 18 to 22 in a9e6aed

	const getXeroSetupLink = (policyID: string) => {
	const params: ConnectPolicyToAccountingIntegrationParams = {policyID};
	const commandURL = getCommandURL({command: READ_COMMANDS.CONNECT_POLICY_TO_XERO, shouldSkipWebProxy: true});
	return commandURL + new URLSearchParams(params).toString();
	};

AccountingSetupWebViewPage then loads that command URL in an incognito WebView and only supplies auth as a first-request Cookie header. In the reported video, the Android WebView shows a blank page with a small "Pretty-print" toolbar instead of the Xero authorization UI, which matches the WebView rendering the command response/raw page instead of following an authenticated setup flow.

App/src/pages/workspace/accounting/AccountingSetupWebViewPage.tsx

Lines 55 to 66 in a9e6aed

	<WebView
	source={{
	uri,
	headers: {
	Cookie: `authToken=${authToken}`,
	},
	}}
	userAgent={getUAForWebView()}
	incognito // 'incognito' prop required for Android, issue here https://github.com/react-native-webview/react-native-webview/issues/1352
	startInLoadingState
	renderLoading={renderLoading}
	/>

The app already has a helper for this kind of OldDot handoff: it requests a short-lived auth token and appends it to the setup URL, but the native Xero setup WebView does not use it.

App/src/libs/actions/Link.ts

Lines 421 to 437 in a9e6aed

	/**
	* Fetches a short-lived auth token and appends it to the given setup link.
	* Falls back to returning the original link if the token request fails.
	*/
	function getShortLivedAuthTokenURL(setupLink: string): Promise<string> {
	// eslint-disable-next-line rulesdir/no-api-side-effects-method
	return API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.OPEN_OLD_DOT_LINK, {}, {})
	.then((response) => {
	if (!response?.shortLivedAuthToken) {
	return setupLink;
	}
	return Url.appendParam(setupLink, 'authToken', response.shortLivedAuthToken);
	})
	.catch((error) => {
	Log.warn('[Link] Failed to fetch short-lived auth token', {error});
	return setupLink;
	});

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

Build the native Xero WebView URL the same way other native OldDot handoffs do: before mounting the WebView, call getShortLivedAuthTokenURL(getXeroSetupLink(policyID)), keep the existing loading state while that promise resolves, and pass the returned URL to AccountingSetupWebViewPage or to the WebView source. This makes the WebView load an authenticated setup URL instead of relying on the raw command URL plus an initial cookie header.

If this is implemented in the shared AccountingSetupWebViewPage, make it opt-in or verify QuickBooks Online still works, because QBO also uses that component. For Xero, keep the Android user agent behavior, and add onOpenWindow/completion-route handling only if the now-authenticated setup page opens a secondary OAuth window during the flow.

Test coverage:

• Add a unit test for the native Xero setup path that mocks getShortLivedAuthTokenURL() and verifies the WebView receives the returned authenticated URL rather than the raw getXeroSetupLink() value.
• If popup handling is added, add a WebView test that simulates onOpenWindow and verifies the target URL is rendered instead of leaving the main WebView blank.
• Manually verify on Android with a new account: enable Accounting, tap Xero, complete/set 2FA, and confirm the Xero authorization UI appears instead of the blank "Pretty-print" page.

What alternative solutions did you explore? (Optional)

Opening the Xero setup URL in the external browser on native would bypass the in-app WebView, but that changes the native accounting setup UX. A narrower fix is to keep the native setup page and give its WebView an authenticated setup URL.

[abbasifaizan70]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Android, when a user without 2FA enabled tries to connect a workspace to Xero, they are correctly prompted to set up 2FA. However, once they finish the 2FA setup and return, instead of continuing into the Xero connection flow, they land on a blank page. The connection is never established.

What is the root cause of that problem?

ConnectToXeroFlow (the native component that drives the "Connect to Xero" flow) decides what to do in a useEffect that runs only once on mount, with an empty dependency array. On first mount, if 2FA is not enabled yet, it opens RequireTwoFactorAuthenticationModal and returns — it never re-runs later. When the user submits that modal, they are simply navigated to the 2FA setup route on top of the current screen; ConnectToXeroFlow is never unmounted.

App/src/components/ConnectToXeroFlow/index.native.tsx

Lines 9 to 23 in 35fece7

	function ConnectToXeroFlow({policyID}: ConnectToXeroFlowProps) {
	const {translate} = useLocalize();
	const {is2FAEnabled, getTwoFactorAuthRoute} = useTwoFactorAuthRoute();
	const [isRequire2FAModalOpen, setIsRequire2FAModalOpen] = useState(false);
	useEffect(() => {
	if (!is2FAEnabled) {
	setIsRequire2FAModalOpen(true);
	return;
	}
	Navigation.navigate(ROUTES.POLICY_ACCOUNTING_XERO_SETUP.getRoute(policyID));
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, []);

is2FAEnabled is reactive — it comes from the account.requiresTwoFactorAuth Onyx value via useTwoFactorAuthRoute — so once the user finishes setting up 2FA and the account updates, is2FAEnabled flips to true in this already-mounted instance. But since the mount-once effect already ran (and did nothing but show the modal), the Navigation.navigate(ROUTES.POLICY_ACCOUNTING_XERO_SETUP...) call is never reached. The component just falls through to return null, which is the blank page the user sees.

This component is never remounted when returning from the 2FA route, because it isn't rendered as its own navigator screen — it's rendered as an always-mounted overlay by AccountingContextProvider, keyed only on activeIntegration.key, which is set once when the "Connect" button is first pressed and does not change again while the user goes through the 2FA flow and back.

App/src/pages/workspace/accounting/AccountingContext/index.tsx

Lines 142 to 149 in 35fece7

	const shouldShowConfirmationModal = !!activeIntegration?.shouldDisconnectIntegrationBeforeConnecting && !!activeIntegration?.integrationToDisconnect;
	return (
	<AccountingStateContext.Provider value={stateValue}>
	<AccountingActionsContext.Provider value={actionsValue}>
	{children}
	{!shouldShowConfirmationModal && renderActiveIntegration()}
	{shouldShowConfirmationModal && (

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

Make the effect react to is2FAEnabled changing (instead of running once on mount), so that once the user finishes setting up 2FA the same mounted instance proceeds into the Xero setup screen instead of silently rendering nothing:

App/src/components/ConnectToXeroFlow/index.native.tsx

Lines 16 to 23 in 35fece7

	useEffect(() => {
	if (!is2FAEnabled) {
	setIsRequire2FAModalOpen(true);
	return;
	}
	Navigation.navigate(ROUTES.POLICY_ACCOUNTING_XERO_SETUP.getRoute(policyID));
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, []);

useEffect(() => {
  if (!is2FAEnabled) {
    setIsRequire2FAModalOpen(true);
    return;
  }
  Navigation.navigate(ROUTES.POLICY_ACCOUNTING_XERO_SETUP.getRoute(policyID));
}, [is2FAEnabled, policyID]);

[mukhrr]

Proposal

What is the root cause of that problem?

This is an Android app-specific WebView gap.

On native, Xero does not open the setup URL externally. ConnectToXeroFlow routes Android users into the in-app setup screen:

App/src/components/ConnectToXeroFlow/index.native.tsx

Lines 16 to 22 in b1fedf2

	useEffect(() => {
	if (!is2FAEnabled) {
	setIsRequire2FAModalOpen(true);
	return;
	}
	Navigation.navigate(ROUTES.POLICY_ACCOUNTING_XERO_SETUP.getRoute(policyID));
	// eslint-disable-next-line react-hooks/exhaustive-deps

That setup screen renders the Xero OldDot connect URL through AccountingSetupWebViewPage:

App/src/pages/workspace/accounting/xero/XeroSetupPage/index.native.tsx

Lines 13 to 18 in b1fedf2

	return (
	<AccountingSetupWebViewPage
	uri={getXeroSetupLink(policyID)}
	testID="XeroSetupPage"
	context="XeroSetupPage"
	/>

But the shared accounting WebView only renders one WebView. It passes the auth cookie and user agent, but does not handle window.open / secondary-window events:

App/src/pages/workspace/accounting/AccountingSetupWebViewPage.tsx

Lines 55 to 66 in b1fedf2

	<WebView
	source={{
	uri,
	headers: {
	Cookie: `authToken=${authToken}`,
	},
	}}
	userAgent={getUAForWebView()}
	incognito // 'incognito' prop required for Android, issue here https://github.com/react-native-webview/react-native-webview/issues/1352
	startInLoadingState
	renderLoading={renderLoading}
	/>

The history supports this being a native accounting WebView capability gap:

• Xero was migrated from an inline native modal WebView to a setup screen on June 3, 2026:
  bcae5f3
• The shared AccountingSetupWebViewPage was extracted on June 30, 2026 and kept the same single-WebView behavior:
  a9c1b52
• A similar native OAuth case, ConnectToHRFlow, already had to support secondary windows with onOpenWindow, popup URL state, and a second WebView:
  

  App/src/components/ConnectToHRFlow/index.native.tsx

  Lines 66 to 69 in b1fedf2

  	const handleOpenWindow = (event: WebViewOpenWindowEvent) => {
  	setPopupUrl(event.nativeEvent.targetUrl);
  	setIsPopupVisible(true);
  	};

  
  

  App/src/components/ConnectToHRFlow/index.native.tsx

  Lines 123 to 143 in b1fedf2

  	// Not using incognito here so the popup WebView can share cookies
  	// with the main flow (required for OAuth handoffs).
  	<WebView
  	source={{uri: authenticatedUrl}}
  	onOpenWindow={handleOpenWindow}
  	onNavigationStateChange={handleNavigationStateChange}
  	startInLoadingState
  	renderLoading={renderLoading}
  	/>
  	)}
  	{!!popupUrl && (
  	<View
  	style={[StyleSheet.absoluteFill, !isPopupVisible && styles.opacity0]}
  	pointerEvents={isPopupVisible ? 'auto' : 'none'}
  	>
  	<WebView
  	source={{uri: popupUrl}}
  	onOpenWindow={handleOpenWindow}
  	startInLoadingState
  	renderLoading={renderLoading}
  	/>

So the blank page happens because Android stays inside the native WebView, Xero’s provider flow opens a secondary window, and AccountingSetupWebViewPage drops that target instead of rendering it.

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

Add secondary-window support to AccountingSetupWebViewPage, following the existing ConnectToHRFlow pattern, while keeping the existing single-WebView behavior unchanged unless a popup is actually requested.

Small illustrative diff:

+import {useState} from 'react';
 import {StyleSheet, View} from 'react-native';
 import {WebView} from 'react-native-webview';
+import type {WebViewOpenWindowEvent} from 'react-native-webview/lib/WebViewTypes';

 function AccountingSetupWebViewPage({uri, testID, context}: AccountingSetupWebViewPageProps) {
+    const [popupUrl, setPopupUrl] = useState<string | null>(null);
+    const [isPopupVisible, setIsPopupVisible] = useState(false);
+
+    const handleOpenWindow = (event: WebViewOpenWindowEvent) => {
+        setPopupUrl(event.nativeEvent.targetUrl);
+        setIsPopupVisible(true);
+    };
+
+    const handleBackPress = () => {
+        if (isPopupVisible) {
+            setIsPopupVisible(false);
+            return;
+        }
+        Navigation.goBack();
+    };

     return (
         <ScreenWrapper ...>
             <HeaderWithBackButton
                 title={translate('workspace.accounting.title')}
-                onBackButtonPress={() => Navigation.goBack()}
+                onBackButtonPress={handleBackPress}
                 shouldDisplayHelpButton={false}
             />
             <FullPageOfflineBlockingView>
-                <WebView
-                    source={{uri, headers: {Cookie: `authToken=${authToken}`}}}
-                    userAgent={getUAForWebView()}
-                    incognito
-                    startInLoadingState
-                    renderLoading={renderLoading}
-                />
+                <View style={styles.flex1}>
+                    <WebView
+                        source={{uri, headers: {Cookie: `authToken=${authToken}`}}}
+                        userAgent={getUAForWebView()}
+                        incognito
+                        onOpenWindow={handleOpenWindow}
+                        startInLoadingState
+                        renderLoading={renderLoading}
+                    />
+                    {!!popupUrl && (
+                        <View style={[StyleSheet.absoluteFill, !isPopupVisible && styles.opacity0]} pointerEvents={isPopupVisible ? 'auto' : 'none'}>
+                            <WebView source={{uri: popupUrl}} onOpenWindow={handleOpenWindow} startInLoadingState renderLoading={renderLoading} />
+                        </View>
+                    )}
+                </View>
             </FullPageOfflineBlockingView>
         </ScreenWrapper>
     );
 }

To avoid regressions:

• Keep the current main WebView source, Cookie, userAgent, incognito, startInLoadingState, and loading UI unchanged.
• Only render the popup WebView after Android emits onOpenWindow, so QBO and any accounting flow that does not open a secondary window behaves the same as today.
• Make back close the popup first, then leave the setup screen. This matches the existing HR OAuth behavior.
• Add/adjust unit coverage for AccountingSetupWebViewPage to verify:
  • the main WebView still receives the original uri and auth cookie;
  • onOpenWindow renders a popup WebView with targetUrl;
  • back hides the popup before calling Navigation.goBack().

What alternative solutions did you explore? (Optional)

Opening Xero in the external browser on Android would avoid the WebView popup issue, but it would change the native accounting setup flow and could affect auth/session redirects. Supporting onOpenWindow fixes the missing Android WebView behavior directly and follows the existing native OAuth pattern already used in the app.