抖音推荐视频字符框输入异常记录(涉及字符倍增与退格失效) 最近发现了抖音里用户“推荐视频”过程中的文本框bug,复现路径很稳定,数据也很有意思,简单记录一下。 先来个省流版: 相当于你在跟一个助理口述内容,说到一半他没等你说完就开始记,记完又接着记你刚才说的,最后记了好几份重叠的版本。你说“删掉最后一个字”,他理解成“好,这也是一条新的输入指令”,又记了一遍。 这个助理需要学会“等对方说完一句话再动笔”,一行代码就能解决——解决方式?可以往下看。 触发条件:切换到系统英文输入法,不点联想词,直接连续键入字母。 现象:键盘上输入“nicenice”的实际输出是这样的↓ 1. n 2. nni 3. nnic 4. nnicnnice 5. nnicnnicen ……懒得打了,也是因为字数限制,各位自己看吧;退格也是坏的,删着删着字反而变多。 这应该是一个经典的IME Composition Event 竞争条件问题。 输入法工作时有一套生命周期:compositionstart→compositionupdate→compositionend。正常情况下,用户点击联想词才会触发 compositionend,handler 处理一次,结束。 但在英文输入法➕不点联想词的场景下,每当输入法感知到“节奏停顿”,就会被动触发一次 compositionend,紧接着为下一个字符重启一个新的composition周期。抖音的handler可能无法区分“用户主动确认”和“输入法内部强制刷新”,把每一次compositionend都当成完整提交处理——于是在DOM里的旧值还没清空的情况下,又把当前值全量写入state。两份数据叠加,产生倍增。 退格失效是同一机制:退格强制关闭当前composition,handler误判为一次提交,写入一次;与此同时新的composition又被触发,再写一次。正反馈了,越删越长。 标准修复方式是加一行“isComposing”的 guard: (Javascript) if (e.nativeEvent.isComposing) return; 让handler在composition进行中保持沉默,只在真正结束时响应一次,问题应该就解决了。 这些都是在不考虑更大的屎山的前提下分析的——如有疏漏,欢迎指正。
00:00 / 00:44
连播
清屏
智能
倍速
点赞20
00:00 / 01:32
连播
清屏
智能
倍速
点赞97
00:00 / 01:17
连播
清屏
智能
倍速
点赞13
00:00 / 01:03
连播
清屏
智能
倍速
点赞16