[Bug 12651] More things should set salvageable to false: XHR, plugins

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12651

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #10 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-09-29 18:51:26 UTC ---
(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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 29 September 2011 18:51:33 UTC