Is your feature request related to a problem?
EnrichedMarkdownText supports text selection (great), but there's no way to make that selection coexist with a tappable parent — which is one of the most common places to render a read-only markdown body: a card / list row that navigates on tap (social feeds, comment lists, chat).
The conflict on native: the selection handles are drawn by the native text view, but a wrapping tap target is a JS Pressable. When the user re-grabs a selection handle on a separate touch to extend the selection, the native handle consumes the drag and hands the touch back to the JS layer as a stationary down→up — so the parent Pressable reads it as a tap and navigates, cancelling the selection interaction. (RN's own <Text selectable onPress> avoids this because onPress on the inner Text claims the responder deepest-first; there's no equivalent hook on EnrichedMarkdownText.)
Because the read-only EnrichedMarkdownText exposes no selection-change event and no general body-tap event, the consumer has no signal to distinguish "user is selecting" from "user tapped to navigate," so the parent can't decide whether to suppress its navigation.
Describe the solution you'd like
Expose onChangeSelection on EnrichedMarkdownText, matching the existing prop on EnrichedMarkdownTextInput:
onChangeSelection?: (selection: { start: number; end: number }) => void;With that, a consumer can track whether a selection is active and have the parent skip navigation while it is (a tap then clears the selection instead of navigating — the standard text-view behavior). That fully resolves the tappable-card case from the app side, with no change to the gesture system.
Alternatives considered
- A general
onPress (body tap) event on EnrichedMarkdownText that claims the JS responder (like RN <Text onPress>) would also work, letting consumers wire tap-to-navigate on the text itself so selection and tap coexist. onChangeSelection feels lower-effort and more consistent with the existing input API.
- Wrapping in a JS
Pressable and using onLongPress to absorb the gesture only covers the initial long-press select, not handle re-grabs.
Additional context
Same maintainers as #615 (which was in the InputMeasurementStore area). This one is renderer-side. Happy to provide a minimal repro (selectable EnrichedMarkdownText inside a Pressable that navigates on press) if useful.
Is your feature request related to a problem?
EnrichedMarkdownTextsupports text selection (great), but there's no way to make that selection coexist with a tappable parent — which is one of the most common places to render a read-only markdown body: a card / list row that navigates on tap (social feeds, comment lists, chat).The conflict on native: the selection handles are drawn by the native text view, but a wrapping tap target is a JS
Pressable. When the user re-grabs a selection handle on a separate touch to extend the selection, the native handle consumes the drag and hands the touch back to the JS layer as a stationary down→up — so the parentPressablereads it as a tap and navigates, cancelling the selection interaction. (RN's own<Text selectable onPress>avoids this becauseonPresson the inner Text claims the responder deepest-first; there's no equivalent hook onEnrichedMarkdownText.)Because the read-only
EnrichedMarkdownTextexposes no selection-change event and no general body-tap event, the consumer has no signal to distinguish "user is selecting" from "user tapped to navigate," so the parent can't decide whether to suppress its navigation.Describe the solution you'd like
Expose
onChangeSelectiononEnrichedMarkdownText, matching the existing prop onEnrichedMarkdownTextInput:With that, a consumer can track whether a selection is active and have the parent skip navigation while it is (a tap then clears the selection instead of navigating — the standard text-view behavior). That fully resolves the tappable-card case from the app side, with no change to the gesture system.
Alternatives considered
onPress(body tap) event onEnrichedMarkdownTextthat claims the JS responder (like RN<Text onPress>) would also work, letting consumers wire tap-to-navigate on the text itself so selection and tap coexist.onChangeSelectionfeels lower-effort and more consistent with the existing input API.Pressableand usingonLongPressto absorb the gesture only covers the initial long-press select, not handle re-grabs.Additional context
Same maintainers as #615 (which was in the
InputMeasurementStorearea). This one is renderer-side. Happy to provide a minimal repro (selectableEnrichedMarkdownTextinside aPressablethat navigates on press) if useful.