[Bug][iOS] Typing or autocorrecting inside a mention strips it to plain text
Los mantenedores suelen responder en 4 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 70/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- ios, objective-c, react-native
Línea de trabajo
Start in the iOS implementation of shouldChangeTextInRange:replacementText: and read MentionStyle.remove:withDirtyRange: plus handleExistingMentions; the issue identifies these paths and getMentionParamsAt: as relevant. Check how edits inside and at the edges of a mention affect its attributes and emitted HTML. Done means typing, autocorrecting, or backspacing cannot leave visible plain text with the mention id silently lost; verify both whole mention deletion and edits beside it.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Description
On iOS, any edit that lands inside a mention silently strips it to plain text. The name stays on screen, the <mention> tag disappears from the emitted HTML, and the id with it — so a reader still sees what looks like a mention, while the application has lost the person it pointed to. In a messaging app that means the mentioned user is never notified, and nothing on screen says so.
This is the same model as #691, which was reported and fixed for Android. That issue states the intended behaviour, and I agree with it:
it should either stay intact or be deleted as a whole atomically
That issue also says the problem is "not reproducible on iOS", where editing "removes the whole mention range instead of leaving orphaned plain text". Reading the current source, that does not seem to be the case: MentionStyle.remove:withDirtyRange: is commented // Strip meta only and calls removeAttribute:MentionAttributeName. The attribute goes; the characters stay.
Steps to reproduce
- In an
EnrichedTextInputwithmentionIndicators={['@']}, insert a mention withsetMention('@', '@Jane Doe', { id: '42' }). - Place the caret in the middle of the name and type one character — or let iOS autocorrect the name, which hits the same path.
- Read
onChangeHtml.
Expected: the mention is untouched (the character landing beside it), or it is removed whole.
Actual: <p>@Jane Dxoe</p> — plain text, no <mention>, no id.
A backspace inside the name does the same thing: one character disappears, and the mention silently stops being one.
Where it comes from
shouldChangeTextInRange:replacementText: consults no mention at any point, so every edit is accepted; handleExistingMentions then compares each mention's stored text to what the storage now holds, and drops the attribute when they differ.
Autocorrect is the worst case: it rewrites a proper noun without the user doing anything deliberate, and there is no way to opt out for a range — autoCorrect (added in 1.2.0, thanks!) is per-input, so turning it off to protect mentions also turns it off for the whole document.
Possible fix
Hold the rule where edits arrive, in shouldChangeTextInRange:replacementText::
- the modified range intersects a mention, and the replacement is empty → remove the whole mention (plus the space
setMentionappended) and returnNO; - it intersects a mention and the replacement is not empty → return
NO.
For a collapsed caret, only strictly inside should count — on either edge the character legitimately belongs beside the mention.
One detail worth noting for whoever implements it: -attribute:atIndex:longestEffectiveRange: fills the range even when the attribute is absent, so a zero-length range is not the signal it appears to be. getMentionParamsAt: returning nil is the reliable check.
I have this running as a local patch against 1.2.0 and I am happy to open a PR if the approach suits you.
Version
react-native-enriched-html 1.2.0, React Native 0.86.3, iOS.
- Lenguaje dominante
- C
- Estrellas
- 1.4k
- Forks
- 76
- Merge medio
- 3 d 8 h
- PR fusionados (30 d)
- 24
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de software-mansion/react-native-enriched-html
-
[Feature request] Vertical spacing (margins) for headings and lists in htmlStylePosiblemente ocupada @henrikra la tomó hace 14 días. Abiertoenhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 20/100
software-mansion/react-native-enriched-html#832 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 4 días
-
[iOS] Tags not parsed on iOS below a certain string lengthPosiblemente ocupada @hejsztynx la tomó hace 22 días. Abiertobug
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
software-mansion/react-native-enriched-html#811 · 3 comentarios ·
Los mantenedores suelen responder en 4 días
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 50/100
software-mansion/react-native-enriched-html#810 · 1 comentario ·
Los mantenedores suelen responder en 4 días
-
Support for `<raw-text-block>`Abiertoenhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
software-mansion/react-native-enriched-html#803 ·
Los mantenedores suelen responder en 4 días
-
<img> wider than its rendering column fails to paint on Android — silently in isolation, with an "invalid measurement" error alongside any other text (not a decode-timing race)Posiblemente ocupada @hejsztynx la tomó hace 42 días. Abiertobug
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
software-mansion/react-native-enriched-html#797 · 2 comentarios ·
Los mantenedores suelen responder en 4 días
Todos los issues de software-mansion/react-native-enriched-html
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
ly05010419/MacNativeGames#1796 ·
Los mantenedores suelen responder en 1 día
-
[Bug] Wi-Fi associates with a distant AP on multi-AP networks (fast scan, no signal sorting)Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
jniebuhr/gaggimate#1009 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Bug :bug:
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
sonic-net/sonic-buildimage#30563 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
llvm/offload-test-suite#1698 ·
Los mantenedores suelen responder en 1 día