This was was cloned from bug 17245 as part of operation convergence.
Originally filed: 2012-05-30 10:54:00 +0000

================================================================================
 #0   contributor@whatwg.org                          2012-05-30 10:54:16 +0000 
--------------------------------------------------------------------------------
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#scroll-to-fragid
Complete: http://www.whatwg.org/c#scroll-to-fragid

Comment:
"Append a new entry at the end of the History object" - there seems to be a
special case when the document is not completely loaded and the navigation
wasn't triggered by user intereaction. In this case Opera + WebKit (always)
and Gecko (sometimes) don't add new history positions for fragment
navigations. This seems like the behaviour that users would expect.

Posted from: 2001:4c28:a030:30:6ca7:4293:d3c0:b9a1
User agent: Opera/9.80 (X11; Linux x86_64; U; Edition Next; en) Presto/2.10.289 Version/12.00
================================================================================
 #1   James Graham                                    2012-05-30 12:26:55 +0000 
--------------------------------------------------------------------------------
This also seems to be the case for non-fragment navigations.
================================================================================
 #2   Ian 'Hixie' Hickson                             2012-05-30 23:16:16 +0000 
--------------------------------------------------------------------------------
Isn't this already handled by the "replacement enabled" logic? If not, could you elaborate on exactly what sequence of events you are thinking of here?
================================================================================
 #3   James Graham                                    2012-05-31 11:11:34 +0000 
--------------------------------------------------------------------------------
Possibly? I find this part of the spec quite confusing although I think this is mainly just because the required behaviour is complex. To the extent that it's because the spec could be clarified, I don't have any concrete suggestions.

The test I had in mind was something like http://hoppipolla.co.uk/tests/navigation/001.html
================================================================================
 #4   Ian 'Hixie' Hickson                             2012-05-31 17:29:48 +0000 
--------------------------------------------------------------------------------
That's a complicated test with many things going on. Which specific part did you have in mind?

If you mean whether setting location replaces the current document or not, that's already taken care of in the definition of the setter. Search the spec for "if the Location object's associated Document object has completely loaded, then the user agent must act as if the assign() method had been called with the new value as its argument. Otherwise, the user agent must act as if the replace() method had been called with the new value as its argument".

Please let me know if that doesn't address your concern.
================================================================================
 #5   James Graham                                    2012-06-01 08:03:46 +0000 
--------------------------------------------------------------------------------
It seems like if I replace the use of the location setter with setting the src of the iframe, I get the same pattern i.e. history.length increases by one if the src is set after the page has loaded but doesn't increase if it is set while the page is loading.
================================================================================