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:
  • HTML: test navigation rate limiting web-platform-tests/wpt#60210
• Implementation bugs are filed:
  • Chromium: N/A
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1922677
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=317129
• MDN issue is filed: pushState() and navigations and history navigation rate limiting no longer throws mdn/content#44477
• 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 )
/infrastructure.html ( diff )
/nav-history-apis.html ( diff )

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