[Bug][iOS] Typing or autocorrecting inside a mention strips it to plain text
メンテナーはふだん 4 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 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日 8時間
- マージ済み PR（30日）
- 24
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
software-mansion/react-native-enriched-html のほかの issue
-
[Feature request] Vertical spacing (margins) for headings and lists in htmlStyle対応中かも @henrikra が 14 日前に担当しました。 オープンenhancement
難易度 4/5 3〜5日 初心者へのやさしさ 20/100
software-mansion/react-native-enriched-html#832 · コメント 1 件 · リアクション 1 件 ·
メンテナーはふだん 4 日以内に返信
-
[iOS] Tags not parsed on iOS below a certain string length対応中かも @hejsztynx が 22 日前に担当しました。 オープン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 1週間以上 初心者へのやさしさ 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 が 42 日前に担当しました。 オープンbug
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
software-mansion/react-native-enriched-html#797 · コメント 2 件 ·
メンテナーはふだん 4 日以内に返信
software-mansion/react-native-enriched-html の issue をすべて見る
似ている issue
-
5700模组网络优先级问题オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
severity: low
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
luainkernel/lunatik#2372 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 75/100
ly05010419/MacNativeGames#1796 ·
メンテナーはふだん 1 日以内に返信
-
ZSTD_decompressStream accepts a Compressed_Block with Block_Size 0 that ZSTD_decompress rejectsオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
jniebuhr/gaggimate#1009 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信