Specify rate limiter for navigation, history traversal, and pushState/replaceState

[zcorpan]

This returns instead of throws for web compat.

Fixes #11108. Fixes #11410.

• At least two implementers are interested (and none opposed):
  • Gecko
  • Chromium (already implemented)
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/browsing-the-web.html ( diff )
/document-sequences.html ( diff )
/nav-history-apis.html ( diff )

[zcorpan]

I guess this should invoke WebDriver BiDi navigation failed.

[farre]

This looks pretty much like how I envisioned. The only thing I'm not entirely sure about about is how this affects step 11 of #navigate. i.e the fact that we'll call #stop-intersection-observing-a-lazy-loading-element, and then just return. Maybe that's fine, but I think someone else needs to say so. Otherwise this LGTM.

[zcorpan]

Yes I put it there to match Chromium's order.

To notice a difference, you would need to do something like call pushState 199 times on a lazy iframe (before it has navigated to its src), then navigate it with location.href (which hits the rate limit), then wait to reset the counter, then make the iframe visible. (Assuming the limit is 200.)

I think it makes some sense that if code attempts to navigate a lazy iframe, it aborts the lazy load, even if the navigation was rate-limited.