1522706 - History.pushState limit may be too low for some live sites

Status: NEW

(Core :: DOM: Navigation, enhancement, P3)

Description

[Thomas Wisniewski [:twisniewski]]

While I personally consider it an abuse of the history pushState mechanism, there is at least one site using it with larger amounts of data (several hundred k per pushState at bol.com when the user changes pages to see more products).

It might be worth revisiting this limit for the sake of interop, though I'm not sure if Chrome has a set limit or something heuristically-driven.

If nothing else I would at least recommend changing the error that's thrown to something more informative than throwing a generic NS_ERROR_ILLEGAL_VALUE exception.

Comment 1

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 2

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 3

[Neha Kochar [:neha]]

The current limit is 2MB (https://searchfox.org/mozilla-central/rev/f372470e10c8cb0691681603a1d6324dee5b3b8a/docshell/base/nsDocShell.cpp#) which is already too large for session history.

Comment 4

[Thomas Wisniewski [:twisniewski]]

This is also affecting the ASDA store locator page.

Comment 5

[Dennis Schubert [:denschub]]

Linking bug 1742168, as it's probably related.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Dennis, do you happen to have recommendation how large buffer we should allow?
Last time I checked blink had some seemingly random limit around 500MB, but I don't know what Webkit does.

Our current limit is 16MB
https://searchfox.org/mozilla-central/rev/3840d8109501fbebdf22212165ea15a391280dcb/modules/libpref/init/StaticPrefList.yaml#1311-1314

Comment 8

[Dennis Schubert [:denschub]]

I'll have to dig into that a bit deeper. I'll report back asap!

Comment 9

[Dennis Schubert [:denschub]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #6)

Dennis, do you happen to have recommendation how large buffer we should allow?
Last time I checked blink had some seemingly random limit around 500MB, but I don't know what Webkit does.

WebKit has a 64MB limit, which feels a lot more reasonable than Google's high limit.

That being said, our outreach in the known case of breakage was successful and they did adjust their implementation, so we don't have any active WebCompat breakage here.

If we see this again, we might have to look at some telemetry data (or rather, add some) to get a feeling about the usual sizes people try to store, and maybe figure out what their use-case is. I get the feeling that people storing large information in the history do this as a hacky workaround, but maybe I'm missing something. It's hard to make any good estimation without having a large number of cases to look at, though :/

Comment 10

[adammpkins]

@denschub Well, when I submitted this, it was because I'm using a library, Inertia.js, which stores the entire request in the history. If you're seeing multiple of these requests, it's likely that they're coming from users of inertia. They note the behavior in their documentation and seem to not see it as a bug. https://inertiajs.com/responses

"To enable client-side history navigation, all Inertia server responses are stored in the browser's history state. It's good to be aware that some browsers impose a size limit on how much data can be saved within the history state.

For example, Firefox has a size limit of 640k characters and throws a NS_ERROR_ILLEGAL_VALUE error if you exceed this limit. This is generally much more data than you'll ever practically need when building applications, but it's good to be aware of this limit when building an Inertia application."

Comment 11

[Dennis Schubert [:denschub]]

I see, thanks for that added info!