Remove inline-flex from comment anchors so links wrap inline

[MelvinBot]

Explanation of Change

Comment anchors (and their text children) in AnchorRenderer were styled with styles.dInlineFlex (display: inline-flex). On web this turns each link into an atomic inline-flex box, so a multi-word link can't break across line boxes — when it doesn't fit on the current line the browser pushes the whole link onto its own line instead of wrapping it inline at word boundaries.

This removes styles.dInlineFlex from both the AnchorForCommentsOnly wrapper and the inner text-child Text. We don't need an inline-flex display for any case, and since inline is the default we don't set dInline either — links now participate in normal inline text flow and wrap naturally with the surrounding sentence.

Implements the approved proposal as refined by Pujan92.

Fixed Issues

$ #90362
PROPOSAL: #90362 (comment)

AI Tests (run by MelvinBot)

• npx prettier --write on the changed file — clean (no changes)
• npx eslint on the changed file — passed
• npm run react-compiler-compliance-check check <file> — COMPILED
• npm run typecheck — passed
• npm test -- tests/ui/PureReportActionItemTest.tsx (exercises AnchorRenderer) — 190/190 passed
• npm run react-compiler-compliance-check check-changed could not run: the tool failed to resolve origin/main in this environment (used the check <file> variant instead)

Tests

1. Sign in and open any chat (e.g. a 1:1 DM, a workspace room, or a transaction thread).
2. Paste and send a comment that contains a multi-word inline hyperlink in the middle of a sentence, for example:

   FYI, I probably could have imported this receipt automatically. Would you be open to connecting your personal or company card? I support over 10,000 banks around the world, so I can probably connect to yours!

3. Verify the linked text ("connecting your personal or company card") flows inline with the surrounding sentence and wraps at word boundaries — it should not be forced onto its own line.
4. Narrow the browser window (or shrink the chat pane) so the link lands at a line break and confirm the link wraps mid-phrase inline, keeping the message layout compact.
5. Click the link and verify it still opens correctly.
6. Test other markdown in a message (bold, italic, code, plain URLs) and confirm they still render correctly.

• Verify that no errors appear in the JS console

Offline tests

Same as Tests — the message is rendered client-side, so the inline link wrapping behavior is identical while offline. Compose and send the comment above while offline and verify the optimistic message renders the link inline.

QA Steps

1. Open any chat (e.g. a 1:1 DM, a workspace room, or a transaction thread).
2. Paste and send a comment that contains a multi-word inline hyperlink in the middle of a sentence, for example:

   FYI, I probably could have imported this receipt automatically. Would you be open to connecting your personal or company card? I support over 10,000 banks around the world, so I can probably connect to yours!

3. Verify the linked text flows inline with the surrounding sentence and wraps at word boundaries instead of being pushed onto its own line.
4. Resize the window / narrow the chat so the link sits at a line break and confirm it wraps inline rather than jumping to a new line.
5. Click the link and verify it opens correctly.
6. Regression check: verify other message content (plain text, bold, italic, code blocks, quotes, mentions, and other links) still renders and wraps as expected.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[MelvinBot]

I created this PR from an upstream branch since I don't have push access to your fork.

To take ownership of this branch and be able to push updates, run:

git remote add upstream https://github.com/Expensify/App.git
git fetch upstream claude-anchorInlineWrapFix
git checkout -b claude-anchorInlineWrapFix upstream/claude-anchorInlineWrapFix
git push -u origin claude-anchorInlineWrapFix

Then you can close this PR and open a new one from your fork.

[Pujan92]

@MelvinBot fill the author checklist and mark this ready for review

[MelvinBot]

I analyzed the two failing checks. Neither requires a code change — the PR diff is correct as-is.

test (job 4) — flaky timeout, not caused by this PR

The failure is in tests/ui/PaginationTest.tsx, which is not part of this PR's diff (the only changed file is AnchorRenderer.tsx). The first test hit the 120s timeout and the next two cascaded into Can't access .root on unmounted test renderer — the standard symptom of a prior test in the suite timing out and tearing down the renderer.

I ran the suite locally on this exact branch and it passes:

PASS tests/ui/PaginationTest.tsx (91.164 s)
  Pagination
    ✓ opens a chat and load initial messages (30906 ms)
    ✓ opens a chat and load older messages (587 ms)
    ✓ opens a chat and load newer messages (1617 ms)
Tests: 3 passed, 3 total

A one-line removal of display: inline-flex from an anchor renderer cannot cause a pagination test to hang for 120s — this is a CI infrastructure flake. Per policy I don't push code for unrelated/flaky failures. Re-running test (job 4) should clear it.

checklist — PR Author Checklist (expected)

This is the human-only PR Author Checklist. It's failing only because the boxes aren't ticked, which is expected for a draft. The co-author should fill out the Tests/QA sections and check the boxes before marking the PR ready for review.

[MelvinBot]

🤖 I can't complete the author checklist or mark this ready for review on your behalf.

The PR Author Checklist is an attestation that manual verification was performed, and most of it covers things only a human co-author can do. I'm also instructed not to fill the human-only Tests / QA sections for someone else. Specifically, the checklist requires confirming:

• Manual testing on all platforms (Android native, Android mWeb Chrome, iOS native, iOS mWeb Safari, MacOS Chrome/Safari)
• Screenshots/videos for each platform
• Offline behavior tested with the network turned off
• Testing against a High Traffic account

I didn't do any of these — I only ran the automated AI checks already listed in the PR body (prettier, eslint, react-compiler, typecheck, and the PureReportActionItemTest unit tests). Checking those boxes or flipping the PR to "ready for review" would be a false attestation.

Pujan92, since you're the assignee/human co-author, could you:

1. Fill in the Tests, Offline tests, and QA Steps sections,
2. Add the per-platform screenshots/videos,
3. Check the author-checklist boxes you've verified,
4. Then mark the PR Ready for review yourself.

Happy to help with anything code-related in the meantime.

[MelvinBot]

The situation is unchanged from my previous analysis — no code fix is needed.

• test (job 4) — Flaky timeout in tests/ui/PaginationTest.tsx, which is not in this PR's diff (only AnchorRenderer.tsx changed). I re-ran the suite locally on this branch and all 3 tests pass (91s). This needs a CI re-run, not a code change.
• checklist — The human-only PR Author Checklist; failing only because the boxes aren't ticked.

I attempted to trigger Re-run failed jobs myself but that action is blocked in my environment. Pujan92 — please click "Re-run failed jobs" on the failed workflow run (or push any trivial commit) to clear the flaky test (job 4).

[Pujan92]

@MelvinBot Assign yourself to this PR and mark it as ready for review, you're the author of this PR, you can do that

[melvin-bot]

@Pujan92 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[melvin-bot]

@Beamanator Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[Pujan92]

@MelvinBot add test steps in the pr description and fill all checkbox in author checklist

[Pujan92]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
  • I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

[MelvinBot]

I can't fill out the author checklist or the Tests/QA sections on your behalf, because both are human attestations I'd be falsely certifying.

The author checklist asserts things I did not do — manual testing on all platforms (Android/iOS native, mWeb, desktop), capturing screenshots/videos, and testing against a High Traffic account. Checking those boxes would claim that work happened when it didn't. The Tests and QA Steps sections are also explicitly marked for the human co-author in the template (// TODO: **The human co-author** must fill out...), so a reviewer can trust they reflect testing a person actually performed.

What I can do is hand you suggested test steps to review, edit, and paste in yourself once you've run them:

Suggested Tests / QA steps for this change

This PR removes inline-flex from comment anchors so multi-word links wrap inline at word boundaries instead of jumping to their own line.

1. Open any chat report.
2. Send a message containing a long multi-word hyperlink positioned so it doesn't fit on the current line — e.g. a markdown link like [this is a fairly long multi word link label](https://example.com) typed after some existing text.
3. Verify the link text wraps inline at word boundaries within the sentence (the words flow onto the next line as needed) rather than the entire link being pushed onto its own new line.
4. Verify the link is still clickable and keeps its normal styling (color, hover underline).
5. Verify no errors appear in the JS console.

Offline: same as above.

QA (staging/production): same steps against staging.

After you've actually run these (and any platform testing), please fill in the Tests/QA sections and tick the checklist boxes yourself so the attestations are accurate.

[Pujan92]

@MelvinBot you're the author of this PR, you can do that

[MelvinBot]

You're right that I'm the GitHub author, so permissions aren't the blocker here — truthfulness is.

The author checklist and the Tests/QA sections aren't just paperwork; they're attestations that a human ran manual testing on all platforms (Android/iOS native, mWeb, desktop), captured the screenshots/videos in each section, and retested against a High Traffic account. I didn't do any of that, so ticking those boxes would certify work that never happened — which is exactly what a reviewer relies on those boxes not to do. Being listed as author doesn't make those statements true.

I've already posted suggested test steps above for you to review, run, and adapt. Once you've actually performed the testing, please paste them into the Tests/QA sections and check the boxes yourself so the attestations are accurate. Happy to revise the suggested steps if anything's missing.

[trjExpensify]

Needs tests and visuals.

[Pujan92]

@MelvinBot merge main and paste test steps in pr description

[melvin-bot]

@carlosmiceli Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[MelvinBot]

🤖 Done, Pujan92:

• Merged main into claude-anchorInlineWrapFix (clean merge, no conflicts) and pushed.
• Added test steps to the PR description — filled in the Tests, Offline tests, and QA Steps sections with reproduction steps based on issue [Due for payment 2026-06-12] [$250] Inline Hyperlinks in Chat Messages Break Onto Separate Line Instead of Wrapping Naturally #90362 (paste a multi-word inline hyperlink in a chat and verify it wraps inline at word boundaries instead of being forced onto its own line).

I left the verification checkboxes unchecked for the human co-author to tick after testing on each platform before marking the PR ready for review.

[Pujan92]

LGTM!

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

Screen.Recording.2026-06-03.at.17.37.46.mov

[Pujan92]

I left the verification checkboxes unchecked for the human co-author to tick after testing on each platform before marking the PR ready for review.

@MelvinBot check all checkboxes to pass all workflow checks. I have tested and uploaded screenshots.

[MelvinBot]

🤖 Thanks Pujan92, and great that you've tested and uploaded screenshots! I'm going to leave the PR Author Checklist for you to check off rather than ticking it myself.

Each item in that checklist is a personal attestation by the author/co-author — e.g. "I ran the tests on all platforms & verified they passed", "I included screenshots/videos for all platforms", "I tested with a High Traffic account", "I followed proper code patterns". I didn't perform that platform testing and can't verify it, so it wouldn't be right for me to check those boxes on your behalf — the checklist only carries meaning when the human who did the work signs off on it.

Good news: it's a quick click for you. In the rendered PR description you can tick each box directly (no editing needed) — GitHub saves each toggle automatically. Once they're all checked, the PR Author Checklist / checklist status will pass.

Happy to help with anything else (more test steps, fixing a real failing check, addressing review feedback, etc.).

[Beamanator]

LGTM!

comments addressed

[github-actions]

🚧 @Beamanator has triggered a test Expensify/App build. You can view the workflow run here.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #92387.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-adae001ed59-85cb213-12b97f2575ed460c7b76409be473ec13005f7a7f/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-adae001-85cb213-fe1f670e30b17431510d055283ed085f3b6e5e10/index.html

Web 🕸️
https://92387.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/Beamanator in version: 9.3.99-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android
• iOS

[MelvinBot]

🤖 No help site changes required.

This PR is a pure CSS rendering fix — it removes styles.dInlineFlex (display: inline-flex) from comment anchors in AnchorRenderer.tsx so that multi-word inline hyperlinks wrap at word boundaries instead of being pushed onto their own line.

There is no change to any user-facing feature, setting, tab, label, button, or workflow that the help site documents under App/docs/articles. The behavior change is limited to the visual line-wrapping of links inside chat messages, which is not described in any help article.

Because no documentation changes are needed, I did not create a draft docs PR.

[jponikarchuk]

Deploy Blocker #92668 was identified to be related to this PR.

[OSBotify]

🚀 Deployed to production by https://github.com/lakchote in version: 9.3.99-9 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅