[whatwg] location.reload() on document.open()ed documents

[Boris Zbarsky]

On 8/24/10 6:13 PM, Ian Hickson wrote:
> So basically, translating this to specese:
>
>     Document objects on which you call open() have an "override reload"
>     flag set and an initially empty source cache added.
>
>     When you call document.write() on a document with the "override reload"
>     flag set, also append the text to the document source cache.
>
>     When you reload a document that has the "override reload" flag set,
>     instead of reloading from the network, just stream the data in from the
>     document source cache.
>
> Is that right?

That seems like an accurate description of the Gecko behavior.  There's 
some weirdness in terms of the document encoding being set to whatever 
it's set to while the data is actually just read directly as UTF-16, 
etc, but that seems like an implementation detail; the spec just needs 
to specify that the data is read as characters, not bytes, and what the 
document encoding should be set to.

>>> Because it ends up with an infinite regression of iframes; the reload
>>> is just making the page load the page instead of about:blank, since
>>> calling document.open() changes the document's address to the caller's
>>> address.
>>
>> Right.  This infinite regression is not a desirable consequence; the
>> spec requiring this behavior seems like a bad idea.
>
> I don't know, it seems pretty desireable to me

 From whose perspective?  The user just hits the reload button, and the 
page suddenly breaks.  Why is this desirable?

> -- it's far simpler than caching the results of document.write()!

Well, sure.  Broken behavior is often simpler to implement than correct 
behavior... ;)

> Also doing this for history navigation is rather scary too, but I guess
> could be done.

History navigation across document.open() is supported in at least IE 
and Gecko right now.  I seem to recall it being rather broken if 
supported at all in Webkit.  I don't know that I've ever tested Opera.

-Boris