Closed
Bug 949471
Opened 11 years ago
Closed 11 years ago
Firefox v26 history.data returns undefined when it should return null
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
FIXED
mozilla29
People
(Reporter: pot, Assigned: bzbarsky)
References
Details
(Keywords: dev-doc-needed, regression, site-compat)
Attachments
(1 file)
5.63 KB,
patch
|
smaug
:
review+
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Assignee: nobody → bzbarsky
Whiteboard: [need review]
Assignee | ||
Updated•11 years ago
|
OS: Windows 8.1 → All
Hardware: x86_64 → All
Summary: Firefox v26 History API does not conform to standard → Firefox v26 history.data returns undefiend when it should return null
Assignee | ||
Comment 3•11 years ago
|
||
Attachment #8346623 -
Flags: review?(bugs)
Assignee | ||
Comment 4•11 years ago
|
||
pot@semlab.nl, thank you for the bug report!
Blocks: 859707
Keywords: regression
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)
Attachment #8346623 -
Flags: review?(bugs) → review+
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. :(
Updated•11 years ago
|
Summary: Firefox v26 history.data returns undefiend when it should return null → Firefox v26 history.data returns undefined when it should return null
Assignee | ||
Comment 7•11 years ago
|
||
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla29
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.
Attachment #8346623 -
Flags: approval-mozilla-aurora?
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Attachment #8346623 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 10•11 years ago
|
||
status-firefox28:
--- → fixed
status-firefox29:
--- → fixed
Updated•11 years ago
|
Keywords: dev-doc-needed,
site-compat
You need to log in
before you can comment on or make changes to this bug.
Description
•