こんにちは。
私は Discourse フォーラム（BlenderArtists.org）のメンバーで、4K モニターを使用しており、フォーラムのページを 2 つ並べて表示できます。
長いコメントを書く予定がある場合、現在の長いスレッドからいくつかの引用を含めて回答を準備する際に、左側のページでメッセージエディターを開き、右側のページで同じスレッドを閲覧することがあります。
しかし、そのようにすると、このメッセージが非常に頻繁に表示されます：
別のウィンドウで下書きが編集されています。このページを再読み込みしてください。
この警告自体には反対しません（確かに特定の状況では有用だと確信しています）。
しかし、ユーザー設定にこれを無効にするオプションを追加することは可能でしょうか？あるいは、表示頻度（タイマー）を設定することは可能でしょうか？
この警告メッセージにより、メッセージを落ち着いて入力することができなくなります。
このオプションの追加をご検討いただき、ありがとうございます。
申し訳ありませんが、この件に関するサポートリクエストが多すぎたため、この警告は意図的なものです。非常にリスクの高い作業であり、投稿全体を失う可能性があります。
ちょっと待って、本当に2箇所で編集していますか？具体的な再現手順を教えてください。
単に開いて閲覧するだけではこの警告は出ません。2つのウィンドウから編集しているはずです。
トピックにアクセスすると、自動的に（試して）下書きの編集が開かれます。コンポーザーをすぐに最小化しても、それはまだライブ状態で、競合が発生します。
はい、私もこの問題に遭遇しました。発生すると確かに面倒ですが、Jeff の意見に同意します。過去の問題から、ここは慎重になる必要があります。
私の対処法は通常、トピックを 2 つのタブで開き、両方が読み込まれてから作曲を始めることです。
これは明らかにバグです。ガードは入力し始めたときのみ発動するはずです。
問題の再現手順が分かれば、修正できます。
私も下書きの自動オープンに悩まされましたが、警告メッセージが表示されるだけよりも深刻です。投稿の入力を再開した後、後でポップアップが表示され、古い下書きがある別のタブに戻ろうとします。その時点でページを更新すると、古いバージョンの下書きしか取得できません。つまり、この機能は本来防ごうとしていることを実際には防いでいないのです。
入力開始前に発生するかどうかはわかりません。meta で再現を試みましたが、2 つ目のタブで入力を始めたときにのみ発生しました。私は通常、書いている内容を参照するためにタブを複製した直後にこの現象を誘発します。どのタブで入力し始めたか見失い、誤って 2 つ目のタブで入力し始めると警告が表示されます。
特定のトピックに対して別のタブですでに作曲器が開いているかどうかを検知し、そうであれば新しいタブでは作曲器を開かないようにすることは可能でしょうか？また、それは合理的なアプローチでしょうか？
それは実際には複雑すぎますね…ウェブワーカーを使って何らかの対策が取れる可能性はありますが、それは非常に大規模な変更であり、行いたくありません。
正確な再現手順が必要です。当社の警告は非常に早期に発動しますし、最悪の場合でも数語を失う程度です。オフライン状態だと奇妙な動作が発生する可能性はありますが、それは非常に特殊なケースです…回避策はコピー＆ペーストです。
ただ、OP（最初の投稿）を確認しました。
これは再現できません。この誤ったメッセージにつながる正確な手順を提供していただけますか。編集していない場合、このメッセージが誤って表示されるのは議論の余地があるとしても1つの特殊なケースだけです。しかし、それは非常に些細な特殊ケースです。
あなたが遭遇している可能性のある問題：
ここで何を修正すべきか確信が持てません…再現手順が必要です。
確かに、重要なコンテンツを大幅に失った経験があります。そのため、この警告をトリガーしないように注意していたので、現時点ではその重大な損失を引き起こした正確な手順を覚えていません。
問題は、これが下書きを保存してタブ 1 で行った内容を上書きする場合ではないでしょうか。もしそうなれば、コンテンツの大幅な損失につながる可能性があります。現時点では推測に過ぎませんが、その方法で問題を再現できるか確認し、ご連絡いたします。
それはあり得ません。お願いします…再現手順が必要です…下書きが保存されるたびに、競合変更のテストが実行されます。
コンテンツの大幅な損失が発生した場合は、手順を段階的に再現できるものを提示してください。
再現手順が必要とされていることは理解しました。明日の夜に確認するようリマインダーを設定しました（
）。衝突テストの仕組みについて、大まかなレベルで教えていただけると助かります。ページ読み込み時に一意の識別子が生成されるなど、何かあるのでしょうか？
各下書きは、一意の ID を通じてコンポーザーと強く関連付けられています。これは前方へのみ適用されます。
これはどういう意味ですか？
つまり、レースが発生した場合、つまり2人の作曲者が同じユーザーの同じトピックに返信している場合、勝つのは常に1人のみです。保存するたびにオーナーが選ばれます。
@sam さん、再現手順をまとめました。これが OP の元の問題に関連するかどうかはわかりません（この会話はずいぶん逸れてしまいましたので）。いずれにせよ、以下に私が把握している状況を記載します。
基本的には、タブ 2 を開いた後、タブ 2 が完全に読み込まれる前にタブ 1 で入力し続けると、新しいページが異常な状態になります。タブ 2 の読み込み中にタブ 1 で入力し続けると、タブ 2 はページが開かれた時点のタブ 1 の下書きを読み込みますが、タブ 1 で追加の変更が保存された後でも、タブ 2 からは編集が可能になります（つまり、その変更が上書きされてしまいます）。
再現手順は以下の通りです。
ステップ #4 においては、タブ 2 の読み込みが完了する前に一度入力を停止して下書きを保存する必要はありません。単に入力を開始するだけで、すべてが異常な状態になります。実際、後で確認するためにバックグラウンドで複製タブを開き、その間にタブ 1 で入力し続けるのは、決して不合理なことではありません。しかし、それを急ぎすぎるとタブが異常な状態になり、タブ 1 で追加した内容を誤って上書きしてしまう可能性があります。もちろん、コンポーザーを最小化しても下書きは保存されるため、この異常な状態に陥った場合、邪魔にならないようにタブ 2 のコンポーザーを最小化しただけで、タブ 1 の最新の下書きが上書きされてしまいます。
この時点で、元メッセージを作成していたタブ 1 に戻ると、入力できなくなり、本来はタブ 2 で表示されるべき警告が表示されます。もし下書きが失われたことに気づいた場合は、もちろんタブ 1 のコンポーザーの内容をコピーできます。しかし、気づかずに警告の指示に従ってページを再読み込みした場合、行った変更を失い、それを取り戻す方法がなくなってしまいます。
これらの手順で問題の再現にまだ問題がある場合は、お知らせください。これらの手順（時には新しいトピックに切り替えて新しい下書きを取得するなど）に従えば、比較的確実に問題を再現できますので、これで十分な情報かと思います。
OK、ここに修正があります：
再現例をありがとうございます。非常に素晴らしく、問題の特定を迅速に行うことができました。
ドラフトバージョンの追跡方法について、以前は少し抽象的な説明しかできていなかったと感じています。私のアルゴリズムが少し単純すぎたうえに、過剰に凝りすぎていたことが原因だと考えられます。それは致命的な組み合わせです。新しいアルゴリズムは、はるかに説明しやすくなっています。
クライアントがドラフトを保存するたびに、サーバーに「自分が持っているシーケンス番号」を伝えます
シーケンス番号が一致した場合、サーバーはシーケンス番号を 1 増やし、新しいシーケンス番号をクライアントに返します
シーケンス番号が一致しない場合、サーバーはクライアントに競合があることを伝え、ドラフトを保存しません
ページの再読み込み時に、サーバーは現在のシーケンス番号をクライアントに伝えます
以前の実装はあまりに凝りすぎており、シーケンスの所有者を追跡することで、多くの条件下でシーケンス番号を増やさないようにしようとしていました。あなたのテストケースは、それがどれほど問題で、コンテンツの損失を引き起こす可能性があるかを示しました。
これは meta サイトで既に公開されています。このシステムに他の境界ケースがあるかどうか、ご確認いただけますでしょうか。
それは大変な称賛ですね、@seanblue。この成果を誇りに思うべきです
Metaでも同じ問題が発生しています：
すでにメッセージをキャンセルしていたにもかかわらず、誤って警告が表示されました：
その後、「破棄する」を選択しても、10〜20秒ごとにこのメッセージが表示されます：
他のタブは開かれていません。
これはトピックからメッセージに変更した場合にのみ発生します。メッセージのキャンセルは実際にはキャンセルされていないようです。
これにはブラウザのタブ間を移動するなど、結構な手間がかかりますが、まあ…この場合の「放棄」は実際に放棄できていないので、修正すべきですね。
