Web-Facing Change PSA: Throw exception when throttling pushState/replaceState

[Chromestatus]

Contact emails

nrose...@chromium.org

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.

Blink component

Blink>History

Web Feature ID

history

Risks

Interoperability and Compatibility

No information provided

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

https://crbug.com/40554715

Estimated milestones

Shipping on desktop	144
Shipping on Android	144
Shipping on WebView	144

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5191802265141248

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

On 11/20/25 3:04 a.m., Chromestatus wrote:

Contact emails

nrose...@chromium.org

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 throwing.

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/691ecb91.050a0220.ba486.0017.GAE%40google.com.

[Noam Rosenthal]

On Thu, Nov 20, 2025 at 10:58 PM Mike Taylor <mike...@chromium.org> wrote:

On 11/20/25 3:04 a.m., Chromestatus wrote:

Contact emails

nrose...@chromium.org

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 throwing

Yes! This change is a part of that effort, which Mozilla is driving. See https://github.com/whatwg/html/issues/11844.

 

[Mike Taylor]

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

[Noam Rosenthal]

On Fri, Nov 21, 2025 at 2:05 PM Mike Taylor <mike...@chromium.org> wrote:
>
> On 11/21/25 5:11 a.m., Noam Rosenthal wrote:
>
> On Thu, Nov 20, 2025 at 10:58 PM Mike Taylor <mike...@chromium.org> wrote:
>>
>> On 11/20/25 3:04 a.m., Chromestatus wrote:
>>
>> Contact emails
>> nrose...@chromium.org
>>
>> 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 throwing
>
>
> Yes! 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.

Note that Safari/Firefox already ships with throwing.
This change was to align with them, with the ability to revert the
flag if any issues come up.

> 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.

That's OK with me; I'll change the runtime flag and take it back to the issue.

>
> thanks,
> Mike

[Noam Rosenthal]

> > 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.
>
> That's OK with me; I'll change the runtime flag and take it back to the issue.

See https://github.com/whatwg/html/issues/11844#issuecomment-3563693096,
and please feel free to chime in.

>
> >
> > thanks,
> > Mike