17093 2012-05-18 09:35:41 +0000 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 ( 2013-04-15 22:31:07 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#opening-the-input-stream P3 normal Unsorted 1 contributor ian adrianba bzbarsky ian james mike travil tross w3c contributor oldest_to_newest 67831 0 contributor 2012-05-18 09:35:41 +0000 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 67833 1 james 2012-05-18 09:36:21 +0000 *** Bug 17091 has been marked as a duplicate of this bug. *** 68333 2 ian 2012-05-30 23:12:39 +0000 I did this IIRC because that's what Gecko does. What does IE do? Are any other browsers interested in changing their behaviour? 68343 3 bzbarsky 2012-05-31 00:28:13 +0000 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. 68344 4 1138 bzbarsky 2012-05-31 00:29:13 +0000 Created attachment 1138 Testcase 68401 5 james 2012-05-31 12:05:29 +0000 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. 68441 6 ian 2012-05-31 17:38:12 +0000 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. 70877 7 contributor 2012-07-18 17:40:32 +0000 This bug was cloned to create bug 18205 as part of operation convergence. 71555 8 ian 2012-07-27 00:11:37 +0000 Not sure what to do here. 71763 9 james 2012-08-02 07:30:57 +0000 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. 75620 10 ian 2012-10-08 20:01:03 +0000 abarth: any comments here? mihaip and bradee-oh might be good people to ping too, but they don't seem to have accounts here. 75628 11 w3c 2012-10-08 20:51:07 +0000 WebKit unlikely to implement the Gecko behavior any time soon because WebKit does not implement wyciwyg. 80705 12 ian 2012-12-30 04:25:13 +0000 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? 84084 13 ian 2013-03-07 22:02:52 +0000 Y'all didn't respond, so I used the definition we used elsewhere for similar things. 84085 14 contributor 2013-03-07 22:03:53 +0000 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 84280 15 bzbarsky 2013-03-12 02:19:49 +0000 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.... 84382 16 ian 2013-03-14 00:37:49 +0000 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. 84387 17 bzbarsky 2013-03-14 00:54:17 +0000 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. 86245 18 ian 2013-04-15 22:30:23 +0000 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. 86246 19 contributor 2013-04-15 22:31:07 +0000 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 1138 2012-05-31 00:29:13 +0000 2012-05-31 00:29:13 +0000 Testcase test.html text/html 299 bzbarsky PCFkb2N0eXBlIGh0bWw+CjxodG1sPgo8Ym9keT4KICA8c2NyaXB0PgogICAgdmFyIGkgPSAwOwog ICAgZnVuY3Rpb24gZm9vKCkgewogICAgICB2YXIgZG9jID0gd2luZG93WzBdLmRvY3VtZW50Owog ICAgICBkb2Mub3BlbigpOwogICAgICBkb2Mud3JpdGUoKytpKTsKICAgICAgZG9jLmNsb3NlKCk7 CiAgICB9CiAgPC9zY3JpcHQ+CiAgPGlucHV0IHR5cGU9ImJ1dHRvbiIgb25jbGljaz0iZm9vKCki IHZhbHVlPSJDbGljayBtZSB0byB3cml0ZSB0aGluZ3MiPgogIDxpZnJhbWU+PC9pZnJhbWU+Cjwv Ym9keT4KPC9odG1sPgo=