Typing or autocorrecting inside a mention strips it to plain text
维护者通常 4 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 70/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- ios, objective-c, react-native
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- C
- 星标
- 1.4k
- 派生
- 76
- 平均合并
- 3 天 10 小时
- 30 天内合并 PR
- 23
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
software-mansion/react-native-enriched-html 的其他 Issue
-
[Feature request] Vertical spacing (margins) for headings and lists in htmlStyle可能已有人在做 @henrikra 于 15 天前认领。 未关闭enhancement
难度 4/5 3-5 天 新手友好度 20/100
software-mansion/react-native-enriched-html#832 · 1 条评论 · 1 个 reaction ·
维护者通常 4 天内回复
-
[iOS] Tags not parsed on iOS below a certain string length可能已有人在做 @hejsztynx 于 23 天前认领。 未关闭bug
难度 4/5 3-5 天 新手友好度 42/100
software-mansion/react-native-enriched-html#811 · 3 条评论 ·
维护者通常 4 天内回复
-
bug
难度 3/5 1-2 天 新手友好度 50/100
software-mansion/react-native-enriched-html#810 · 1 条评论 ·
维护者通常 4 天内回复
-
enhancement
难度 5/5 一周以上 新手友好度 35/100
software-mansion/react-native-enriched-html#803 ·
维护者通常 4 天内回复
-
<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)可能已有人在做 @hejsztynx 于 43 天前认领。 未关闭bug
难度 4/5 3-5 天 新手友好度 55/100
software-mansion/react-native-enriched-html#797 · 2 条评论 ·
维护者通常 4 天内回复
查看 software-mansion/react-native-enriched-html 的全部 Issue
相似的 Issue
-
contrib/ivorysql_ora/src/builtin_packages/utl_file/utl_file.c:517 - FCOPY destroys a file when source and destination are the same可能已有人在做 @Metastarx 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 75/100
ly05010419/MacNativeGames#1848 ·
维护者通常 1 天内回复
-
libc++ test-suite
难度 2/5 1-3 小时 新手友好度 85/100
llvm/llvm-project#239851 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 77/100
-
bug game: 010042D00D900000 mac
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复