This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17245 - "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
Summary: "Append a new entry at the end of the History object" - there seems to be a s...
Status: RESOLVED WORKSFORME
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-30 10:54 UTC by contributor
Modified: 2012-12-05 20:41 UTC (History)
3 users (show)

See Also:

Attachments

Description contributor 2012-05-30 10:54:16 UTC 
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
Comment 1 James Graham 2012-05-30 12:26:55 UTC 
This also seems to be the case for non-fragment navigations.
Comment 2 Ian 'Hixie' Hickson 2012-05-30 23:16:16 UTC 
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?
Comment 3 James Graham 2012-05-31 11:11:34 UTC 
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
Comment 4 Ian 'Hixie' Hickson 2012-05-31 17:29:48 UTC 
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.
Comment 5 James Graham 2012-06-01 08:03:46 UTC 
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.
Comment 6 contributor 2012-07-18 17:40:59 UTC 
This bug was cloned to create bug 18207 as part of operation convergence.
Comment 7 Ian 'Hixie' Hickson 2012-09-26 03:48:15 UTC 
<iframe src> setting was fixed recently as part of another bug. Any other cases?
Comment 8 James Graham 2012-12-03 10:14:50 UTC 
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.
Comment 9 Ian 'Hixie' Hickson 2012-12-04 00:03:56 UTC 
That's the location setter, so the spec already defines that as far as I can tell. (See paragraph 2 of comment 4.)
Comment 10 James Graham 2012-12-04 13:41:19 UTC 
Oh of course. Sorry.

I can't currently find a case that isn't either iframe related or location setter related.
Comment 11 Ian 'Hixie' Hickson 2012-12-05 20:41:26 UTC 
Excellent.

If you do, please don't hesitate to reopen the bug or file a new one, of course.