17245 2012-05-30 10:54:16 +0000 "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 2012-12-05 20:41:26 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WORKSFORME http://www.whatwg.org/specs/web-apps/current-work/#scroll-to-fragid P3 normal Unsorted 1 contributor ian ian james mike contributor oldest_to_newest 68305 0 contributor 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 68308 1 james 2012-05-30 12:26:55 +0000 This also seems to be the case for non-fragment navigations. 68336 2 ian 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? 68392 3 james 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 68439 4 ian 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. 68482 5 james 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. 70881 6 contributor 2012-07-18 17:40:59 +0000 This bug was cloned to create bug 18207 as part of operation convergence. 74536 7 ian 2012-09-26 03:48:15 +0000 <iframe src> setting was fixed recently as part of another bug. Any other cases? 79268 8 james 2012-12-03 10:14:50 +0000 I haven't checked, but are cases like: data:text/html;charset=utf-8,%3C!DOCTYPE%20html%3E%0A%3Cscript%3Elocation.href%3D%22data%3Atext%2Fhtml%2CHistory%20length%20before%20navigation%3A%20%22%20%2B%20history.length%20%2B%20%22%3B%20after%20navigation%20%3Cscript%3Eonload%3Dfunction()%20%7Bdocument.body.firstChild.textContent%20%2B%3D%20history.length%7D%3C%22%20%2B%20%22%2Fscript%3E%22%0A%3C%2Fscript%3E handled? That doesn't involve an iframe at all. 79336 9 ian 2012-12-04 00:03:56 +0000 That's the location setter, so the spec already defines that as far as I can tell. (See paragraph 2 of comment 4.) 79400 10 james 2012-12-04 13:41:19 +0000 Oh of course. Sorry. I can't currently find a case that isn't either iframe related or location setter related. 79500 11 ian 2012-12-05 20:41:26 +0000 Excellent. If you do, please don't hesitate to reopen the bug or file a new one, of course.