Bogus history entries get created in FF 3.6.2

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load the youtube.html file from the source control package in FireFox 
3.6.2. I haven't tested it in any others but it's probably the same 
behaviour
2. Look at the browser history.

What is the expected output? What do you see instead?
There should be no browser history, instead you see 3 browser history 
entries

What version of the product are you using? On what operating system?
FireFox 3.6.2 windows vista 32bit. Note: It doesn't happen on linux.

Please provide any additional information below.
To fix this problem don't call .close() on the dynamically created iframe.

Original issue reported on code.google.com by rup...@gmail.com on 31 Mar 2010 at 2:44

[GoogleCodeExporter]

I've run into this issue as well, on both Firefox 3.6 & 3.6.2.  I've also 
confirmed 
that the behavior is newly introduced, as identical code does not result in the 
duplicate history entry in Firefox 3.5.8. 

I'm not so certain that leaving out a call to .close() will resolve anything.  
By 
stepping through the jsonp code in firebug, I've isolated the document.open() 
call on 
line 201 to be the step where the duplicate history entry is created.

I've mitigated the negative impact of this firefox bug by inserting code that 
adds a 
fragment ID to the url through a location.replace() call within the cleanup 
function 
when an affected version of firefox is detected.  While this does nothing to 
eliminate the extra history entry, it does change the current history item so 
it is 
no longer the same as the duplicate, thus re-enabling the back button (firefox 
seems 
to refuse to navigate between identical history entries) 

I've attached a patch with the code I've put in place, and while it's no 
general 
solution it at least lessens the blow when the page using jsonp makes no use of 
the 
fragment ID part of the URL.  Unfortunately, I've no idea how we can avoid the 
firefox bug, so a solution that eliminates the duplicate entries altogether 
would be 
most welcome.

Original comment by mike.lan...@gmail.com on 31 Mar 2010 at 4:30

[GoogleCodeExporter]

Upon further investigation I think you are correct in that it's not the call to 
.close() that is the problem. It seems the problem occurs in the clean up for 
garbage 
collection. When you write the empty string to the iframe it creates a new 
history 
entry.

This actually makes sense and it's the same technique Google maps uses to 
create 
history when you make searches.

Is it actually necessary to clear the existing document in the iframe?

Original comment by rup...@gmail.com on 6 Apr 2010 at 5:58

[GoogleCodeExporter]

That's really weird... why on earth would FF put iframes without src attribute 
into the 
history? Seems like a FF bug to me I'll have to live with :/

As to know if the iframe code needs to be cleared... well, I'll know when I 
work more 
on the leak in IE problem.

Original comment by aubourg.julian on 6 Apr 2010 at 2:43

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Issue 16 has been merged into this issue.

Original comment by aubourg.julian on 6 Apr 2010 at 2:44

[GoogleCodeExporter]

Taking ownership.

Original comment by aubourg.julian on 6 Apr 2010 at 2:45

[GoogleCodeExporter]

This issue was closed by revision r43.

Original comment by aubourg.julian on 7 Apr 2010 at 4:49

• Changed state: Fixed

[GoogleCodeExporter]

Which mean version 1.1.4

Original comment by aubourg.julian on 7 Apr 2010 at 4:57

[GoogleCodeExporter]

I can also confirm version 1.1.4 fixes a problem with IE6 history.  The previous
version was clobbering history in IE6 whereas the new version doesn't.  This 
means
JSONP now plays nicely with Ben Alman's hashchange plugin, ref:
  http://github.com/cowboy/jquery-hashchange/issues/closed#issue/4

Original comment by richowil...@gmail.com on 7 Apr 2010 at 7:26