1199924 - History.pushState() and History.replaceState() methods store unnecessary 'null' state object

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[arni2033]

State object is set to null by default. But when a page sets state object === null, then it's threated as an object with size==4 (bigger than 0)
This generally isn't necessary and may cause additional issues (exceptions in console that interrupt JS) if preference "browser.history.maxStateObjectSize" is set to ≤ 3
https://hg.mozilla.org/releases/mozilla-esr38/file/aa2ecb8673b1/docshell/base/nsDocShell.cpp#l11408
Line 11355:
> -> 11355   Preferences::GetInt("browser.history.maxStateObjectSize", 0xA0000);

Jonas, I'm asking you because you had reviewed a patch in bug 500328
Please tell if this is valid bug and if the importance of this bug is worth the effort

Comment 1

[arni2033]

Sorry, it's line 11494. That part of code is same on m-c; I posed ESR 38 link because it's static
> -> 11494   Preferences::GetInt("browser.history.maxStateObjectSize", 0xA0000);

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not sure if this bug is technically correct or not, I.e. I'm not sure if the spec requires us to return 'null' from .state as default. Either way I don't think it's worth the effort to fix no since it only affects users that change the browser.history.maxStateObjectSize pref in about:config to a value less than 4.

Comment 3

[Boris Zbarsky [:bzbarsky]]

We currently just store the JS value as the state, which does in fact require an extra allocation.  We _could_ add a special case for the state being null and avoid allocating the storage for it in that situation.  That might be worthwhile to avoid the extra allocation, perhaps.  It's not worth it if we're just worried about the maxStateObjectSize interaction.