On 11/21/25 5:11 a.m., Noam Rosenthal wrote:
On Thu, Nov 20, 2025 at 10:58 PM Mike Taylor <[email protected]> wrote:On 11/20/25 3:04 a.m., Chromestatus wrote:*Contact emails* [email protected] *Specification* https://html.spec.whatwg.org/multipage/nav-history-apis.html#shared-history-push/replace-state-steps *Summary* Calling pushState/replaceState more than 200 of times/second would throw an exception instead of failing silently. This aligns with existing Gecko & WebKit behavior.Is there a plan to specify this (interoperable) behavior? After step 10, HTML talks about implementation-defined limits, but not about throwingYes! This change is a part of that effort, which Mozilla is driving. See https://github.com/whatwg/html/issues/11844.
Great, thanks for the pointer. Looking at the many comments at https://github.com/livewire/livewire/discussions/7746, this doesn't seem like a safe change - even if this framework fixes their code, who knows how many sites will never get upgraded, and will be broken in Chrome as well as Firefox and Safari.
It seems like the more compatible path forward would be for Firefox and WebKit to align with Chromium (and the current spec, given that throwing is Optional...), or perhaps there's a middle ground to increase the limit from 200 to 500 or 1000 or something that covers 80% of scenarios like this (even if they seem like weird edge cases).
Given that this is definitely going to break sites, this should be an Intent to Ship instead of a PSA (sorry to be _that_ API Owner) and we should dig in a bit more to learn what is the blast radius. if possible, getting some UseCounter and/or histogram data would be helpful.
thanks, Mike -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/63427470-3984-4fb0-85a7-fb9aaebf17d9%40chromium.org.
