Response over 320k causing an error in Firefox on pushState

[pprewett-cmi]

I'm running into an odd problem with the library in Firefox.

Initially, it appeared that we had an intermittent problem when calling history.pushState(...), but I've narrowed it down to only occurring when the data I'm trying to push is over 320k in size and I'm using the Firefox browser (v18.0.2). The error I'm getting back from the firebug console is:

NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMHistory.pushState]

This same size response causes no problems in either Chrome or IE.

The specific call is: history.pushState({ tab: tabId, html: data }, reportName, queryString);

where tabId, reportName, & queryString are all trivially short (1, 10, & ~25-30 chars respectively).

The exact same call works fine as long as the data parameter is < 320k. I've experimented with different characters to see if it was some type of encoding issue, but it does not appear to be. I have slowly approached the 320k limit by adding "0"'s to the response and adding that one extra "0" will tip it over the edge and cause the exception.

Has anyone seen this behavior before? Any ideas on workarounds?

[pprewett-cmi]

Hmmm... Just found in the mozilla docs where they limit the size to 640k, so there must be some encoding or something else that's going on here that doubles the size before it pushes and then I get the error. Seems like a relatively small size, but oh well. Won't be forking Firefox anytime soon.

https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history

[skerit]

Each character in a JavaScript string takes 16 bytes, so that's why it seems like the limit is halved. I'm having the same problem now, and I'm thinking about using this in-browser compressor (which uses the full capabilities of utf-16) http://pieroxy.net/blog/pages/lz-string/index.html

[pprewett-cmi]

So what we did here was put in some code to evaluate the size of the state before attempting to push and if it's too large, we just put a URL its place and if, during a pop operation, we find a URL instead, we just load that from the server instead of restoring state from history. It's not often that we have page sizes that are this large, so it turns out not to be a huge problem for us.

I would appreciate you letting me know how things go with the compressor. That would be a better solution if it works well. Thanks.