Obviously, not all WebKit's reasons to prevent page caching need to be standardized, and some of them probably can't be easily deconstructed.

A few cases are hiding under canSuspendActiveDOMObjects(), such as Workers and running IDBTransactions.

Should this be defined in XMLHttpRequest?

It'd make sense for the XHR spec to cover XHR's interaction here. But there are other things besides XHR.

mass-move component to LC1

I assume you mean "more things should set salvageable _to false_".

I'm happy to add more things, or add hooks for other specs if necessary (I think hooks already exist though).

The only case I could find from the source above that looked relevant is that we can't bfcache a page if anything in its browsing context involves a live plugin.

The other things didn't look like things we should add to the spec, though. For example, why would the use of shared workers affect it? Why would encrypted pages be affected?

Gecko bfcaches pages with plug-ins and just stops/restarts the plug-in.  It's caused us a few compat issues, but not very many, and there's been work to provide a better stop/restart in NPAPI so that plug-ins can play nicely with bfcache.

So I don't think we should add plug-ins to the list of things that make pages not salvageable.

Gecko also doesn't have any XHR specific code. We do however prevent bfcaching of any page which has open network connections.

Potentially ideally we should exempt EventSource from this so network connections held open by a page using EventSource *doesn't* set salvageable to false.

But any other network connections, such as dynamically loaded <img> or XHR causes the salvageable flag to be false.

And for these purposes, "network connections" include connections to the filesystem. So a FileReader which is currently reading a Blob or File will also cause salvageable to be false.

Why do you set salvageable to false if you've got an open network connection up, rather than just finishing the download (especially if it's only been going for a few milliseconds)?

Note that the browser is always allowed to throw out a bfcached page; I could add some text saying that if a network connection is prematurely aborted then it should be thrown out, if you like.

> Why do you set salvageable to false if you've got an open network connection
> up, rather than just finishing the download

Several reasons:

1)  For just about every network connection, download completion needs to trigger an event handler, which is a really weird thing to do in an unloaded page.  This is certainly the case for XHR.

2)  At least in Gecko, the data structure tracking in-progress network access is attached to the WindowProxy (because you have to be able to treat a load as starting in one page but finishing in another).  So on page transition requests have to be canceled so as not to affect onload in the new page.

3)  Having unloaded pages consume network resources is very much contrary to user expectations.

> (especially if it's only been going for a few milliseconds)?

I don't see why this is an "especially" or why it matters.

(In reply to comment #9)
> 1)  For just about every network connection, download completion needs to
> trigger an event handler, which is a really weird thing to do in an unloaded
> page.  This is certainly the case for XHR.

The way the spec is written today, the task for that event would get queued, and the event loop skips tasks from documents that aren't active, so the event would fire once the document was made active again.


> 2)  At least in Gecko, the data structure tracking in-progress network access
> is attached to the WindowProxy (because you have to be able to treat a load as
> starting in one page but finishing in another).  So on page transition 
> requests have to be canceled so as not to affect onload in the new page.

Ok.


> 3)  Having unloaded pages consume network resources is very much contrary to
> user expectations.

Yeah, I completely agree that if the download is using up resources then it deserves to be dropped if it's not active.


> > (especially if it's only been going for a few milliseconds)?
> 
> I don't see why this is an "especially" or why it matters.

I figure some browsers will want the following model to work:

 - user is on a page.
 - every now and then, the page causes a very brief network request.
 - the user clicks a link on the page.
 - user then hits the back button.

If the user clicked the link while no network request was active, hitting the back button will be fast, because it'll be bfcached. But if a request _was_ active, then it'll be slow. The user can't tell the difference.


Anyway. Per spec, the browser is allowed to discard a document in the bfcache whenever it wants. I think we should only be aborting documents and setting their salvageable flag to false in cases where there is really no way that bfcache can work (e.g. when there's an unload event handler). We shouldn't be disallowing cases where implementation difficulties mean that it doesn't work today, but where one could imagine another browser, or the same browser after lots of work, doing it in a way that allowed bfcache.

(Note that one exception to this currently is that the spec requires document loads that are in-progress during a navigation to be aborted, regardless of whether it's truly necessary or not. I added that recently, because every browsers does it. Maybe it was a mistake, though.)


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: Rejected
Change Description: no spec change
Rationale: It doesn't seem any of the cases listed in this bug are cases where we cannot imagine a browser successfully using bfcache, so we shouldn't preclude it in those cases. I'm happy to add cases if there are some that are actual problems in all cases.