View source for Firefox3.1/XHR Progress Events Security Review

== Overview ==
This feature allows scripts to track upload of XMLHttpRequest.
1.9 already has uploadprogress events, but this adds support for
events which are defined in XMLHttpRequest2 and ProgressEvents Drafts.

;Background links
* https://bugzilla.mozilla.org/show_bug.cgi?id=435425
* http://dev.w3.org/2006/webapi/progress/Progress.html
* http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
* http://www.w3.org/TR/DOM-Level-2-Events/
* http://mozilla.pettay.fi/xhr_upload/xhr_upload_demo.html

== Security and Privacy ==
* Whenever handling events, it must happen using the right script context. And the context must be alive. So in practice event target must check that its "owner" inner window has still an outer window, and the inner window of that outer window must be the owner window.
* XMLHttpRequest and upload are bound to their owner window and they ensure that the owner is alive and all using nsXHREventTarget::CheckInnerWindowCorrectness(). A mochitest was added to test this.

== Exported APIs ==
* Adding/removing event listeners using .addEventListener/.removeEventListener or using onEventName syntax. Similar events for XMLHttpRequest and for its new property .upload. 
* Events: loadstart, progress, error, abort, load
* Since the feature is based on W3C drafts, it is expected that the user of the API knows relevant drafts.
* While implementing progress events, the interfaces for XMLHttpRequest didn't change, but internal nsPIDOMEventTarget got a new method and IID was updated.

== Data ==
* XMLHttpRequest and .upload store event listeners using nsEventListenerManager, which is used also for all DOM Nodes and |window|. Special handling for onEventName properties is needed, so a simple wrapper is created for those event listeners before passing them to nsEventListenerManager.

== Reliability and Configuration ==
* User can't configure the feature in any way. Nor can developer using #ifdefs etc. There is no user interaction with the feature.

== Relationships to other projects ==
* Cross-site XMLHttpRequest implements some other parts of XMLHttpRequest2, and it disables upload progress events in some cases.

== Review comments ==
* In the cross-site case with uploadprogress events page content can use them to tell if a given server exists (presumably, one inside a firewall).
* what if windowA scripts starts an XHR in windowB (same-origin)? which gets the events? what happens if one or both navigate while the events are coming in?
* These events are available to worker threads, for XHR created by that worker.