FP10 breaks FileReference even more?!

So. It was already broken over ssl in Firefox and anytime with a self-signed cert. Fine.

Question: When Adobe says:

Quote:

---

Any existing content that invokes a browse dialog box using Filereference.browse or FileReference.download outside of an event triggered by user interaction will need to be updated. The dialog box will now have to be invoked through a button, keyboard shortcut, or some other event initiated by the user.

---

What the hell do they mean, exactly? How does the player determine this? I mean, does browse() or download() only need to be in a function that takes an event as an argument? Can that argument be null? Can you have another display object create a MouseEvent to fake it? I've got a multiple file uploader running on six live sites right now, in which max simul. uploads is 3, so when a user tries to u/l 10 files, it waits on one to be completed then starts the fourth. If I'm reading this right, file #4 will never upload, because it's not occurring simultaneously with a MouseEvent. ?!!! Can that possibly be true? And what's the hack?

Okay, so the uploader still works with FP10.
Not one of the uploads is triggered by a click. The click starts a timer, which tells the first [concurrent#] of FileReferences to upload and then checks once a second to see who's done. So...what's their security patch here? If a TimerEvent will do, then will any event do? What do they mean, how does this work, and why the **** do they have to be so obscure and circumspect about it?

Nobody wants to weigh in on this one :confused: