527618 - when remote XMLHttpRequest success callback tries to update hash via location.href, current session history entry is replaced ("Back" skips the entry)

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, defect)

Description

["Cowboy" Ben Alman]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5

When I make a cross-domain XMLHttpRequest request, if the success callback tries to change the hash by setting location.href = baseurl + "#hash" instead of location.hash = "#hash", the previous location loses its history entry, such that hitting the back button actually skips back two locations.

See my blog post here:
http://benalman.com/news/2009/11/is-this-a-firefox-remote-xhr-bug/

Reproducible: Always

Steps to Reproduce:
1. Make a cross-domain XMLHttpRequest request with a success callback that sets the hash via location.href = baseurl + "#hash";
2. Press the back button once.

Actual Results:  
The history goes back two locations, instead of one.

Expected Results:  
The history should go back one location.

I've observed this behavior in Firefox 2 - 3.6, on both Mac and Windows.

Comment 1

["Cowboy" Ben Alman]

This also happens when appending an arbitrary script tag to the head or body. For example, append this script and the same thing happens; the history goes back two locations, instead of one.

<script>location.href=location.href.replace(/#.*/,"")+"#foo";</script>

Is this some kind of security thing?

Comment 2

[Nickolay_Ponomarev]

Any chance you could attach a minimized testcase using plain XMLHttpRequest without jQuery? I can reproduce the #4 from the linked page in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b8pre) Gecko/20101025 Firefox/4.0b8pre

As for comment 1 "appending an arbitrary script tag" - did you mean appending in the HTML source or dynamically?

Comment 3

[Jiri Kopsa]

I can confirm this too. To clarify, the title of this bug should be:

"When SCRIPT onload callback (aka JSONP callback) tries to update hash via location.href, current session history entry is replaced ("Back" skips the entry)".

However, there seems to be some strange conditions required. I'm getting the buggy behavior in a complex application built using Google Closure JSONP and history objects.

However, plain simple test case does not reproduce this:
http://barunkad.savana.cz/jiri.kopsa/testcase-firefox-hash-jsonp.html

Comment 4

[Boris Zbarsky [:bzbarsky]]

I believe this is the same underlying issue as bug 754029 (which has patches and whatnot).

Comment 5

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Hi Ben,

I have test this issue on latest Firefox (44.0.2) release, latest Nighty (47.0a1) build and I have manged to reproduce it with the URL provided. 

Firefox: 47.0a1, Build ID: 20160301030237
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Firefox: 44.0.2, Build ID: 20160210153822
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.

I am unable to provide more reduce test case, can you please provide one like Nickolay suggested in comment 2? 

Thanks,
Cosmin.

Comment 6

[Adam Vandolder [:avandolder]]

This appears to still be valid, like bug 754029.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:zcorpan, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 8

[Simon Pieters [:zcorpan]]

Attachment: fragment-navigation-without-user-interaction-back.html

Comment 9

[Simon Pieters [:zcorpan]]

Attachment: fragment-navigation-without-user-interaction-back-2.html

Comment 10

[Simon Pieters [:zcorpan]]

STR:

1. Open a new tab.
2. Navigate to https://bugzilla.mozilla.org/attachment.cgi?id=9548127
3. Follow instructions in the test.

Actual result
Navigates back 2 steps to the new tab page.

Expected result
Navigate back 1 step.

This bug is expecting the opposite of what was implemented in bug 1515073. At this point, the XHR event handler doesn't make any difference, as far as I can tell. Any fragment navigation that wasn't a result of user interaction is intentionally skipped by the back button.

Closing as WONTFIX.