[$250] Workspace - User can see cursor `no-drop` on regular text in Workflows and Reports pages

[izarutskaya]

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.3.0-6
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @dubielzyk-expensify
Slack conversation (hyperlinked to channel name): #expensify_bugs

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Create a workspace > try hover over cursor to regular text in Reports and Workflows pages

Expected Result:

User shouldn't have cursor no-drop on regular text in Workflows and Reports in the workspace editor.

Actual Result:

User sees cursor no-drop on regular text in Workflows and Reports pages.

Workaround:

Unknown

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

CleanShot.2026-01-13.at.14.24.41.mp4

CleanShot.2026-01-13.at.14.23.42.mp4

Recording.3567.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022014061561186243391
• Upwork Job ID: 2014061561186243391
• Last Price Increase: 2026-01-21
• Automatic offers:
• nyomanjyotisa | Contributor | 110237792

Issue Owner

Current Issue Owner: @iwiznia

[melvin-bot]

Triggered auto assignment to @heyjennahay (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[ShridharGoel]

Proposal

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

In the workspace editor, regular text in Workflows and Reports shows a no-drop cursor.

What is the root cause of that problem?

The toggle row uses a pressable wrapper that defaults to an interactive cursor when it does not receive a boolean false for interactivity. When the row has no onPress, the code still marks it as a button and treats it as disabled, which triggers the disabled cursor. After removing the disabled state, the same area shows a pointer because interactivity is undefined.

App/src/pages/workspace/workflows/ToggleSettingsOptionRow.tsx

Lines 191 to 199 in 8378ac5

	<View style={[styles.flexRow, styles.alignItemsCenter, styles.justifyContentBetween, shouldPlaceSubtitleBelowSwitch && styles.h10]}>
	<PressableWithoutFeedback
	style={[styles.flexRow, styles.alignItemsCenter, styles.flex1]}
	onPress={shouldMakeContentPressable ? onPress : undefined}
	accessibilityLabel={title}
	role="button"
	accessible={false}
	disabled={!shouldMakeContentPressable}
	>

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

Make the content area non-interactive unless it is both active and has an onPress handler. Only set the button role when it is actually pressable. This keeps the cursor default on regular text while preserving the button cursor for real interactions.

const shouldMakeContentPressable = !!(isActive && onPress);
<PressableWithoutFeedback
    style={[styles.flexRow, styles.alignItemsCenter, styles.flex1]}
    onPress={shouldMakeContentPressable ? onPress : undefined}
    accessibilityLabel={title}
    role={shouldMakeContentPressable ? 'button' : undefined}
    accessible={false}
    interactive={shouldMakeContentPressable}
>
    {contentArea}
</PressableWithoutFeedback>

[situchan]

I believe cursor should be text (not default) when hover text, similar to #79401 (comment)

[nyomanjyotisa]

Proposal

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

Workspace - User can see cursor no-drop on regular text in Workflows and Reports pages

What is the root cause of that problem?

The PressableWithoutFeedback component wraps the content area and always has role="button", which causes the cursor to show as cursorPointer or cursorDisabled (no-drop) even when the content is not pressable

Currently, when shouldMakeContentPressable is false, we sets disabled={true}, which makes BaseGenericPressable return cursorDisabled (not-allowed cursor)

App/src/pages/workspace/workflows/ToggleSettingsOptionRow.tsx

Lines 192 to 199 in 5e875e2

	<PressableWithoutFeedback
	style={[styles.flexRow, styles.alignItemsCenter, styles.flex1]}
	onPress={shouldMakeContentPressable ? onPress : undefined}
	accessibilityLabel={title}
	role="button"
	accessible={false}
	disabled={!shouldMakeContentPressable}
	>

The cursor style logic in BaseGenericPressable returns cursorText only when role="presentation" and interactive={true}

App/src/components/Pressable/GenericPressable/implementation/BaseGenericPressable.tsx

Lines 71 to 87 in 5e875e2

	const cursorStyle = useMemo(() => {
	if (!interactive) {
	return styles.cursorDefault;
	}
	if (shouldUseDisabledCursor) {
	return styles.cursorDisabled;
	}
	if (onPress) {
	return styles.cursorPointer;
	}
	if ([rest.accessibilityRole, rest.role].includes(CONST.ROLE.PRESENTATION) && !isNested) {
	return styles.cursorText;
	}
	return styles.cursorPointer;
	}, [onPress, interactive, shouldUseDisabledCursor, rest.accessibilityRole, rest.role, isNested, styles.cursorPointer, styles.cursorDefault, styles.cursorDisabled, styles.cursorText]);

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

We should conditionally set the role prop based on whether the content is pressable. When it's not pressable, use role="presentation" to get the text cursor. When it is pressable, use role="button" to get the pointer cursor

                    <PressableWithoutFeedback
                        style={[styles.flexRow, styles.alignItemsCenter, styles.flex1]}
                        onPress={shouldMakeContentPressable ? onPress : undefined}
                        accessibilityLabel={title}
                        role={shouldMakeContentPressable ? 'button' : 'presentation'}
                        accessible={false}
                        interactive={true}
                    >

App/src/pages/workspace/workflows/ToggleSettingsOptionRow.tsx

Lines 192 to 199 in 5e875e2

	<PressableWithoutFeedback
	style={[styles.flexRow, styles.alignItemsCenter, styles.flex1]}
	onPress={shouldMakeContentPressable ? onPress : undefined}
	accessibilityLabel={title}
	role="button"
	accessible={false}
	disabled={!shouldMakeContentPressable}
	>

What alternative solutions did you explore? (Optional)

None

New-Expensify.mp4

[yatin-italy]

Proposal

Restate the problem this issue is trying to solve.
Regular, non-clickable text in Workspace Workflows and Reports shows a no-drop cursor. It should show a default or text cursor.

What is the root cause of that problem?
The row uses PressableWithoutFeedback with button semantics and interactivity even when onPress is absent. BaseGenericPressable then applies a disabled cursor.

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

const shouldMakeContentPressable = Boolean(isActive && onPress);

<PressableWithoutFeedback
    style={[styles.flexRow, styles.alignItemsCenter, styles.flex1]}
    onPress={shouldMakeContentPressable ? onPress : undefined}
    accessibilityLabel={title}
    role={shouldMakeContentPressable ? 'button' : 'presentation'}
    accessible={false}
    interactive={shouldMakeContentPressable}
>
    {contentArea}
</PressableWithoutFeedback>

• Gate interactivity on shouldMakeContentPressable (requires both active + handler).
• Use role="button" only when pressable; otherwise use role="presentation" to show a default/text cursor.
• Set interactive={shouldMakeContentPressable} so BaseGenericPressable does not emit the disabled (no-drop) cursor for plain text.

What alternative solutions did you explore? (Optional)
None.

[bernhardoj]

Proposal

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

Disabled cursor is shown when hovering over the workflow sub items title.

What is the root cause of that problem?

Each section uses ToggleSettingsOptionRow and the title area is wrapped with a Pressable so it's pressable when an onPress is passed to the component.

App/src/pages/workspace/workflows/ToggleSettingsOptionRow.tsx

Lines 192 to 201 in 232cb11

	<PressableWithoutFeedback
	style={[styles.flexRow, styles.alignItemsCenter, styles.flex1]}
	onPress={shouldMakeContentPressable ? onPress : undefined}
	accessibilityLabel={title}
	role="button"
	accessible={false}
	disabled={!shouldMakeContentPressable}
	>
	{contentArea}
	</PressableWithoutFeedback>

But when no onPress is passed, the button is disabled, thus the disabled cursor is shown.

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

We can conditionally render the pressable based on shouldMakeContentPressable.

{shouldMakeContentPressable ? (
    <PressableWithoutFeedback
        style={[styles.alignItemsCenter, styles.flex1]}
        onPress={onPress}
        accessibilityLabel={title}
        role="button"
        accessible={false}
    >
        {contentArea}
    </PressableWithoutFeedback>
) : contentArea}

OPTIONAL:
We can further improve the component structure so there is no multiple div rendered when it's pressable.
First, remove the View wrapper here (so it becomes a fragment <></>),

App/src/pages/workspace/workflows/ToggleSettingsOptionRow.tsx

Lines 161 to 162 in 232cb11

	const contentArea = (
	<View style={[styles.flexRow, styles.alignItemsCenter, styles.flex1]}>

and move it here instead.

{shouldMakeContentPressable ? (
    <PressableWithoutFeedback
        style={[styles.flexRow, styles.alignItemsCenter, styles.flex1]}
        onPress={onPress}
        accessibilityLabel={title}
        role="button"
        accessible={false}
    >
        {contentArea}
    </PressableWithoutFeedback>
) : (
    <View style={[styles.flexRow, styles.alignItemsCenter, styles.flex1]}>
        {contentArea}
    </View>
)}

[melvin-bot]

@heyjennahay Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

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