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 12838 - Define garbage collection policy
Summary: Define garbage collection policy
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: XHR (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-31 23:13 UTC by Simon Pieters
Modified: 2011-08-18 11:42 UTC (History)
3 users (show)

See Also:

Attachments

Description Simon Pieters 2011-05-31 23:13:51 UTC 
XHR should say that an XHR object is not to be garbage collected if it can still get events and has listeners for those events. Compare with WebSocket API.
Comment 1 Simon Pieters 2011-08-17 11:33:41 UTC 
I think something along the following:

UNSENT, OPENED with send() flag false 
can be GC (no need to mention in the spec)

OPENED with send() flag true
must not be GC if there are any listeners for readystatechange, loadstart, progress, abort, error, load, timeout, loadend

HEADERS_RECEIVED
must not be GC if there are any listeners for readystatechange, progress, abort, error, load, timeout, loadend

LOADING
must not be GC if there are any listeners for readystatechange, progress, abort, error, load, timeout, loadend

DONE
can be GC (no need to mention in the spec)

If an XHR object is GC when it is in OPENED with send() flag true, HEADERS_RECEIVED, or LOADING, then the UA must act as if the user aborted the request.
Comment 2 Simon Pieters 2011-08-17 12:12:35 UTC 
websocket has:

"A WebSocket object with an established connection that has data queued to be transmitted to the network must not be garbage collected."

Possible that XHR should say something similar.
Comment 3 Anne 2011-08-17 15:14:28 UTC 
EventSource has a much simpler garbage collection policy. Would be interesting to know why that is not sufficient here.