513640 - XMLHttpRequest Level 2 progress event loses reference to container

Status: UNCONFIRMED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Ryan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1) Gecko/20090806 Namoroka/3.6a1 (.NET CLR 3.5.30729)

I have a demo I setup of drag'n drop uploading. I attach progress events to the upload attribute on the XMLHttpRequest. Before I post the request I create pointer to the current containing item using xhr.upload.log = document.getElementById("item"+index) index being the current iteration in the for loop.

On some items, not all, it will lose reference to the xhr.upload.log object in the progress event and the error console will say event.target.log is undefined and then from there will disrupt all other uploads, they will still upload but none of them will have the progress or load events fire from that point on.

I can't consistently re-create this issue as I haven't narrowed down what exactly causes it to happen, could be an issue with my JavaScript? I do however have a screencast of the error happening here http://screenr.com/w18. I am uploading a lot of images at the same time in the screencast but I have had it happen on a single upload too.

Reproducible: Sometimes

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Does the problem happen only on FF3.6 or also on FF3.5?

Comment 2

[Ryan]

This functionality only works in FF3.6 so I can't test it in FF3.5, the access of local files through a drop event that is. Testing the demo in FF3.5 just opens the dragged image(s) in the current tab.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

If you could create a minimal testcase, which doesn't use DnD, but just XHR.

Comment 4

[Ryan]

Ok created a minimal test case using 3 file inputs I get the same error http://www.thecssninja.com/demo/drag-drop_upload/test.html took another screencast also showing the error http://screenr.com/6O8

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

And does the problem happen both on FF3.5 and 3.6/trunk or only 3.6/trunk?

Comment 6

[Ryan]

Yes Both in FF3.5.2 and 3.6 a1.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

What happens if you add load listener to the xhr, not only to xhr.upload.
Because I think without any listeners in xhr, and without any references to xhr, 
it may get cycle collected.

I wonder if xhr.upload should keep xhr alive.

Comment 8

[Ryan]

So I added a load listener to the xhr, http://www.thecssninja.com/demo/drag-drop_upload/test.html, it still seems to be happening and it's random when it does fail. The only other change was putting the event.target.log.firstChild.nextSibling.firstChild into a variable in the uploadProgressXHR function.

I even removed the xhr.log reference and the xhr load listener, essentially putting it back to how it was in comment #4, and it is happening less but it does still happen both with and without a reference and a load listener directly on the xhr.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

I wonder why this http://mozilla.pettay.fi/xhr_upload/xhr_file_upload_demo_with_speed.html doesn't trigger the problem.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Ah, hmm, there is the setInterval call in that demo which takes xhr/xhr.upload as parameter, so those are kept alive.

Has bug 382871 regressed somehow. If it has, then you need to keep a reference
to the XHR object.

Comment 11

[Ryan]

I assumed that setInterval was purely there to update the speed for the example and not keep alive the xhr reference. Seems like a hack to do that to keep the reference alive.

Comment 12

[Hallvord R. M. Steen [:hallvors]]

Hi Ryan, this test seems to be written according to somewhat older versions of the relevant specs - had to use file.size instead of file.fileSize and do xhr.send(file) instead of xhr.sendAsBinary(file.getAsBinary()) stuff. Could you update the demo? Do you still see the problem?

TIA! :-)