Queued up events are supposed to get processed the next frame, but in practice it is not true!

Question

According to Adobe's documentation found here, there are 3 parts to runtime code execution: events, the enterFrame event, and rendering. Events, it says, are processed during the first part. It then states:
If events occur during other parts of the execution cycle, the runtime queues up those events and dispatches them in the next frame.
However, when I'm seeing a low framerate, and lots of input events occur (say mouseclicks for example), those events are sometimes not executed until several seconds and 10s of frames later. According to that documentation, all my mouseclicks should be processed on the next frame and the event queue should then be empty (assuming I don't click during the next frame). This problem only occurs in Firefox and Internet Explorer. Chrome, Safari, and the standalone player behave correctly, in that they process all input events on the following frame.
Why is this happening? It seems like the Firefox and IE plugins implement event handling differently than what is described in the flash documentation, or is it possible the browsers are responsible for delaying the input to flash?

Answer 1

each clock cycle, if no new objects were created and no previously created objects are eligible for gc:
Flash checks for any events completed from the previous cycle.
Then it executes the listener function code, if there is any, for those events.
Then if you have code on a frame that was just entered, that code will execute.
Then it dispatches the Event.ENTER_FRAME event to all your listeners for that event.
Then the display is rendered.
in view of that and knowing that time alone cannot be used to determine in which cycle anything occured in flash, what evidence do you have that an event dispatched in one cycle failed to be detected by a listener in the next cycle?