Originally detected on Facebook in Firefox 12 by Matt Kruse
Test scripts may be found here, the userscript has been separated below the HTML test page
Original test page may be here: http://socialfixer.com/temp/replacestate.html
It was discovered that when Facebook calls history.replaceState that document-start scripts fire again.
"I also noticed that FB is calling replaceState with only two arguments, and no url."
Greasemonkey is injecting scripts and testing (aProgress.isLoadingDocument) before running scripts: https://github.com/greasemonkey/greasemonkey/blob/master/content/browser.js#L29
Related event documentation: https://developer.mozilla.org/En/XUL/Method/AddTabsProgressListener
Additionally a sample of some of the code that may be triggering these problems can be found here https://gist.github.com/2837089
Whether or not this is a moz bug, a facebook bug, or a GM oversight is tbd, since the tab is not loading a new document when the history state is replaced, the URL did not change (in this case), yet the page seems to think it isLoadingDocument again.
When navigating a site, history.pushState and history.replaceState should not trigger a document-start script to run again. One of these passes the test and the other does not.
"history.replaceState() operates exactly like history.pushState() except that replaceState() modifies the current history entry instead of creating a new one."
#1565 may have changed this
The thread linked was from May 2012, when 0.9.20 was the live version. When I install 0.9.20 into Firefox 18.0.1, I see two alerts as described. When I install 1.7.1, I do not, I just see the first.
Closing this as obsolete; it was probably fixed by #1565 as mentioned above.