[$1000] App doesn't open a new tab when clicking on a URL of staging on production

[kavimuru]

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

---

Action Performed:

1. Go to production
2. Open any report
3. Copy a deep link of staging i.e https://staging.new.expensify.com/settings/profile/display-name
4. Send the link as a message in report
5. Click on the link

Expected Result:

App should open a new tab to redirect to the page in staging

Actual Result:

App doesn't open a new tab and the link is production link

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.38-2
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Screencast.from.06-07-2023.00_53_10.webm

Expensify/Expensify Issue URL:
Issue reported by: @dukenv0307
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1688619360838289?thread_ts=1688135098.594039&cid=C049HHMV9SM

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01e923e4ff221ffae9
• Upwork Job ID: 1678503120618921984
• Last Price Increase: 2023-08-07
2023-07-17
• Automatic offers:
• situchan | Contributor | 25863058
• dukenv0307 | Reporter | 25863059
• Talha345 | Contributor | 26077438

[melvin-bot]

Triggered auto assignment to @adelekennedy (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[tienifr]

Proposal

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

App doesn't open a new tab when clicking on a URL of staging on production

What is the root cause of that problem?

In

App/src/components/HTMLEngineProvider/HTMLRenderers/AnchorRenderer.js

Lines 29 to 33 in b9f1d47

	const internalNewExpensifyPath =
	(Url.hasSameExpensifyOrigin(attrHref, CONST.NEW_EXPENSIFY_URL) || Url.hasSameExpensifyOrigin(attrHref, CONST.STAGING_NEW_EXPENSIFY_URL)) &&
	!CONST.PATHS_TO_TREAT_AS_EXTERNAL.includes(attrPath)
	? attrPath
	: '';

We're opening the link internally if the url has the same origin with staging link (https://staging.new.expensify.com) or production link (https://new.expensify.com)

App/src/components/HTMLEngineProvider/HTMLRenderers/AnchorRenderer.js

Lines 51 to 54 in b9f1d47

	if (internalNewExpensifyPath) {
	Navigation.navigate(internalNewExpensifyPath);
	return;
	}

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

We should create a new function to check internal origin

On website platforms

    hasNewExpensifyOrigin(attrHref){
 return Url.hasSameExpensifyOrigin(attrHref, window.location.origin);
}

On others platforms, we don't have window.location.origin and I think we shouldn't open link internally on native/desktop platform if the hostname is localhost. That why I want to preserve the current main logic here

    hasNewExpensifyOrigin(attrHref){
 return Url.hasSameExpensifyOrigin(attrHref, CONST.NEW_EXPENSIFY_URL) || Url.hasSameExpensifyOrigin(attrHref, CONST.STAGING_NEW_EXPENSIFY_URL);
}

and change this line

App/src/components/HTMLEngineProvider/HTMLRenderers/AnchorRenderer.js

Line 30 in b105aa3

(Url.hasSameExpensifyOrigin(attrHref, CONST.NEW_EXPENSIFY_URL) || Url.hasSameExpensifyOrigin(attrHref, CONST.STAGING_NEW_EXPENSIFY_URL)) &&

to

            hasNewExpensifyOrigin(attrHref) &&

Unfortunately, the current hasSameExpensifyOrigin function doesn't support http://localhost:8080 so I want to change the getURLObject to support all the kinds of link

Change URL_WEBSITE_REGEX to MARKDOWN_URL_REGEX, baseUrl=match[3], protocol = match[4];

Result

Screen.Recording.2023-07-20.at.11.58.38.mov

[adelekennedy]

Reproduced and up to date on the Slack thread

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01e923e4ff221ffae9

[melvin-bot]

Current assignee @adelekennedy is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[Talha345]

Proposal

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

If a staging link (staging.new.expensify.com) is sent on production app via a chat message ,the app treats it like an internal link and tries to open it internally via react-navigation instead of opening it in a new tab as an external link.

What is the root cause of that problem?

App/src/components/HTMLEngineProvider/HTMLRenderers/AnchorRenderer.js

Lines 29 to 33 in b105aa3

	const internalNewExpensifyPath =
	(Url.hasSameExpensifyOrigin(attrHref, CONST.NEW_EXPENSIFY_URL) || Url.hasSameExpensifyOrigin(attrHref, CONST.STAGING_NEW_EXPENSIFY_URL)) &&
	!CONST.PATHS_TO_TREAT_AS_EXTERNAL.includes(attrPath)
	? attrPath
	: '';

The internalNewExpensifyPath is only checking if the given link is an internal new expensify link i.e it is either a production or a staging link and not verifying the link with the current URL host.

App/src/components/HTMLEngineProvider/HTMLRenderers/AnchorRenderer.js

Lines 49 to 54 in b105aa3

	// If we are handling a New Expensify link then we will assume this should be opened by the app internally. This ensures that the links are opened internally via react-navigation
	// instead of in a new tab or with a page refresh (which is the default behavior of an anchor tag)
	if (internalNewExpensifyPath) {
	Navigation.navigate(internalNewExpensifyPath);
	return;
	}

Since, the conditions are true here as the given link is a staging link, so it is opened internally via react-navigation.

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

App/src/components/HTMLEngineProvider/HTMLRenderers/AnchorRenderer.js

Lines 23 to 33 in b8aeec0

	const isAttachment = Boolean(htmlAttribs[CONST.ATTACHMENT_SOURCE_ATTRIBUTE]);
	const displayName = lodashGet(props.tnode, 'domNode.children[0].data', '');
	const parentStyle = lodashGet(props.tnode, 'parent.styles.nativeTextRet', {});
	const attrHref = htmlAttribs.href || '';
	const attrPath = lodashGet(Url.getURLObject(attrHref), 'path', '').replace('/', '');
	const hasExpensifyOrigin = Url.hasSameExpensifyOrigin(attrHref, CONFIG.EXPENSIFY.EXPENSIFY_URL) || Url.hasSameExpensifyOrigin(attrHref, CONFIG.EXPENSIFY.STAGING_API_ROOT);
	const internalNewExpensifyPath =
	(Url.hasSameExpensifyOrigin(attrHref, CONST.NEW_EXPENSIFY_URL) || Url.hasSameExpensifyOrigin(attrHref, CONST.STAGING_NEW_EXPENSIFY_URL)) &&
	!CONST.PATHS_TO_TREAT_AS_EXTERNAL.includes(attrPath)
	? attrPath
	: '';

1. In the above code, calculation of attrPath is changed like this to accomodate DEV urls since attrPath is calculated from getURLObject method which utilizes a regex from here to match the provided URL and the regex does not take into account URLs such as localhost:8080 for DEV envs.:

const isDevUrl = attrHref.startsWith(CONST.DEV_NEW_EXPENSIFY_URL);
    const attrPath = isDevUrl ? Url.getPathFromDevURL(attrHref) : lodashGet(Url.getURLObject(attrHref), 'path', '').replace('/', '');

Making changes to the mentioned Regex just to accomodate localhost is not feasible because of the way it has been structured and used.

where getPathFromDevURL

function getPathFromDevURL(url) {
    const path = new URL(url).pathname;
    return path.substring(1); // Remove the leading '/'
}

2. A new simpler method to compare the origin of the provided URL with the current URL. (KISS principle)

function hasSameOrigin(url1, url2) {
    const host1 = new URL(url1).host;
    const host2 = new URL(url2).host;
    return host1 === host2;
}

3.Then using const {environmentURL} = useEnvironment(); from here like this: const hasSameOrigin = Url.hasSameOrigin(attrHref, environmentURL);

4. The if clause for internalNewExpensifyPath is updated as follows:

const internalNewExpensifyPath =
        (Url.hasSameExpensifyOrigin(attrHref, CONST.NEW_EXPENSIFY_URL) || Url.hasSameExpensifyOrigin(attrHref, CONST.STAGING_NEW_EXPENSIFY_URL) || isDevUrl) &&
        !CONST.PATHS_TO_TREAT_AS_EXTERNAL.includes(attrPath)
            ? attrPath
            : '';

5. And finally:

if (internalNewExpensifyPath && hasSameOrigin) {
            Navigation.navigate(internalNewExpensifyPath);
            return;
        }

I would also like to use https://www.npmjs.com/package/react-native-url-polyfill package to make the new URL(url) object work across all platforms since RN URL polyfill has known issues ,see https://github.com/charpeni/react-native-url-polyfill#why-do-we-need-this.

The methods getPathFromDevURL and hasSameOrigin in my proposal do not have guard clauses for invalid URLs which I will obviously add in the PR.

What alternative solutions did you explore? (Optional)

Result

For Result after this implementation, please see #22523 (comment)