pot Reporter
	Description • 11 years ago

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131202182626

Steps to reproduce:

When my website gets opened, the main Javascript file does the following test (snippet):

if(window.history.state !== null && window.history.state.page)
{
	link = window.history.state.page;
}

(window.history.state or history.state does not make a difference. Behavior also shown when asking for the state directly in the console)


Actual results:

In Firefox version 26 (stable and beta channels) I get the following Javascript console error (apart from the fact my site isn't functioning):
"TypeError: window.history.state is undefined"


Expected results:

According to the standards:
"The state attribute of the History interface must return the last value it was set to by the user agent. Initially, its value must be null."
(http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#dom-history-state)
And this is the way it behaves in Chrome, Opera, Internet Explorer (11) and Firefox (prior to version 26).

Now if there was a part of my code actually setting the state to undefined, I would expect this to happen in other browsers as well. Apart from that, I also executed "history.state" in the Javascript console on various other websites (including Google and this very form) and on these occasions it returned undefined as well.
This leads me to believe this is incorrect behavior of Firefox.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 1 • 11 years ago

nsHistory::GetState definitely returns JS::UndefinedValue() at the end, if !variant

That seems like a regression from bug 859707, which indeed landed in Firefox 26.  Before that bug, the only non-throwing case was:

  return doc->GetStateObject(aState);

Now we do:

  doc->GetStateObject(getter_AddRefs(variant));
  if (variant) {
    // return its data
  }

  return JS::UndefinedValue();

which is clearly a behavior change.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 2 • 11 years ago

Gah.  The only test coverage we seem to have for this is test_bug500328.html, which is disabled.  And it wouldn't have caught the issue anyway because is() is broken.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 4 • 11 years ago

pot@semlab.nl, thank you for the bug report!

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 5 • 11 years ago

Comment on attachment 8346623 [details] [diff] [review]
history.state should be null, not undefined, when there is no state.

(assuming the changes to test_bug500328.html actually pass)

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 6 • 11 years ago

That test is disabled, actually...  and it fails if enabled even without my changes, due to an exception getting thrown as it runs.  :(

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 7 • 11 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/47efe38fe540

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 8 • 11 years ago

Comment on attachment 8346623 [details] [diff] [review]
history.state should be null, not undefined, when there is no state.

I think it's worth backporting this to Aurora, but probably not to beta.

 [Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 859707.
User impact if declined: Some sites may not work correctly.
Testing completed (on m-c, etc.): Passes tests.
Risk to taking this patch (and alternatives if risky): This should be very low
   risk, since it just restores the behavior Firefox 25 and other browsers have.
String or IDL/UUID changes made by this patch:  None.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 9 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/47efe38fe540

	Ryan VanderMeulen [:RyanVM]
	Comment 10 • 11 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/40e9753ec0ee