18207 2012-07-18 17:40:55 +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 2013-02-18 12:02:53 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED WORKSFORME http://www.whatwg.org/specs/web-apps/current-work/#scroll-to-fragid P3 normal --- 1 contributor dave.null ian james mike public-html-admin public-html-wg-issue-tracking robin public-html-bugzilla oldest_to_newest 70880 0 contributor 2012-07-18 17:40:55 +0000 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. ================================================================================ 83263 1 robin 2013-02-18 12:02:53 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: none Rationale: See discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17245#c10