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 17093 - Step 25 - we (Opera) would prefer to follow WebKit and not add a new history position when doing document.open. The utility of this to users is questionable since many cases where it is used the content of the document before document.open is not useful (
Summary: Step 25 - we (Opera) would prefer to follow WebKit and not add a new history ...
Status: RESOLVED FIXED
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:
: 17091 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-05-18 09:35 UTC by contributor
Modified: 2013-04-15 22:31 UTC (History)
8 users (show)

See Also:

Attachments
Testcase (299 bytes, text/html)
2012-05-31 00:29 UTC, Boris Zbarsky 		Details

Description contributor 2012-05-18 09:35:41 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#opening-the-input-stream
Complete: http://www.whatwg.org/c#opening-the-input-stream

Comment:
Step 25 - we (Opera) would prefer to follow WebKit and not add a new history
position when doing document.open. The utility of this to users is
questionable since many cases where it is used the content of the document
before document.open is not useful (e.g. it is a blank document) and other DOM
operations can be just as destructive, but not create new history positions.
In addition, any page that does document.open onload can leave the user in a
situation where it is hard to navigate back past a given point in history
because every time they load that page, an extra position is created.

Posted from: 2001:4c28:a030:30:219:99ff:fe0e:5501
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-18 09:36:21 UTC 
*** Bug 17091 has been marked as a duplicate of this bug. ***
Comment 2 Ian 'Hixie' Hickson 2012-05-30 23:12:39 UTC 
I did this IIRC because that's what Gecko does. What does IE do? Are any other browsers interested in changing their behaviour?
Comment 3 Boris Zbarsky 2012-05-31 00:28:13 UTC 
IE has the same behavior as Opera as far as I can tell.  When doing document.open on an initial about:blank document no SHEntry is added, and when doing it in other cases one is added.  I'll attach a testcase that can be used to test this.

I would be fine with switching Gecko to the current IE/Opera behavior in the medium term (and in fact I have wanted to do so in the past, but it's been stymied by Gecko not having a good concept of "initial about:blank" yet; we're working on that, though).

We got a number of bug reports about not being able to go back and forward across document.open before we implemented our current behavior, iirc, but this was a while ago.
Comment 4 Boris Zbarsky 2012-05-31 00:29:13 UTC 
Created attachment 1138 [details]
Testcase
Comment 5 James Graham 2012-05-31 12:05:29 UTC 
I think our plan was to move more in the direction of WebKit than the current Opera behaviour. But we would be open to arguments that the WebKit  behaviour is more user-hostile than the current Opera behaviour.
Comment 6 Ian 'Hixie' Hickson 2012-05-31 17:38:12 UTC 
If we change something here, I think it'd be better to change it towards the IE/Opera behaviour described above, where initial about:blank pages force "replaced" to true, and otherwise it's unchanged. Especially in light of comment 3 paragraph 3.
Comment 7 contributor 2012-07-18 17:40:32 UTC 
This bug was cloned to create bug 18205 as part of operation convergence.
Comment 8 Ian 'Hixie' Hickson 2012-07-27 00:11:37 UTC 
Not sure what to do here.
Comment 9 James Graham 2012-08-02 07:30:57 UTC 
Neither are we :)

I think we are sold on the WebKit behaviour not being ideal, so maybe the IE/current Opera behaviour is the one to spec in the hope that WebKit will align? You should probably ask someone from WebKit if they are strongly attached to their current behaviour.
Comment 10 Ian 'Hixie' Hickson 2012-10-08 20:01:03 UTC 
abarth: any comments here? mihaip and bradee-oh might be good people to ping too, but they don't seem to have accounts here.
Comment 11 Adam Barth 2012-10-08 20:51:07 UTC 
WebKit unlikely to implement the Gecko behavior any time soon because WebKit does not implement wyciwyg.
Comment 12 Ian 'Hixie' Hickson 2012-12-30 04:25:13 UTC 
Ok, I'm going to make it so that if we're at the initial about:blank when you do document.open() then it does it with replacement, and otherwise it does not.

However, I don't know what "the initial about:blank" is exactly. If you mutate it via the DOM, is it still the initial about:blank? What's the definition I should use here?
Comment 13 Ian 'Hixie' Hickson 2013-03-07 22:02:52 UTC 
Y'all didn't respond, so I used the definition we used elsewhere for similar things.
Comment 14 contributor 2013-03-07 22:03:53 UTC 
Checked in as WHATWG revision r7738.
Check-in comment: document.open() replaces when the current doc is the initial about:blank
http://html5.org/tools/web-apps-tracker?from=7737&to=7738
Comment 15 Boris Zbarsky 2013-03-12 02:19:49 UTC 
It's not clear to me from the definition you used whether doing open() and then close() and then another open() will cause the second open() to be a replace or not....
Comment 16 Ian 'Hixie' Hickson 2013-03-14 00:37:49 UTC 
It's the same Document all the way through, so yes, both would be replace() assuming that the Document is the first (aka about:blank) Document created for the browsing context when the browsing context was created.

Is that not Web-compatible? If so, please don't hesitate to reopen the bug, that's easy to change.
Comment 17 Boris Zbarsky 2013-03-14 00:54:17 UTC 
I don't think it's web-compatible enough.  Once there's been one open/close the document should no longer be considered an initial document, imo.
Comment 18 Ian 'Hixie' Hickson 2013-04-15 22:30:23 UTC 
Roger. I keyed this off whether 'unload' gets invoked, since that seemed a pretty good indicator that the document is no longer fresh. That ok? Reopen if not.
Comment 19 contributor 2013-04-15 22:31:07 UTC 
Checked in as WHATWG revision r7838.
Check-in comment: Make document.open() do a replace only once
http://html5.org/tools/web-apps-tracker?from=7837&to=7838