Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix a race condition involving the
waitForEvent
integration test he…
…lper function Debugging mozilla#17931 uncovered a race condition in the way we use the `waitForEvent` function. Currently the following happens: 1. We call `waitForEvent`, which starts execution of the function body and immediately returns a promise. 2. We do actions to trigger the event. 3. We await the promise, which resolves if the event is triggered or the timeout is reached. The problem is in step 1: function body execution has started, but not necessarily completed. Given that we don't await the promise, we immediately trigger step 2 and it's not unlikely that the event we trigger arrives before the event listener is actually registered in the function body of `waitForEvent` (which is slower because it needs to be evaluated in the page context and there is some other logic before the actual `addEventListener` call). This commit fixes the issue by turning `waitForEvent` into a generator, which allows us to only give control back to the caller when the event listener is fully registered. Now the following happens: 1. We call `waitForEvent`, which starts execution of the function body and immediately returns a promise. 2. We call `next()` to advance to the `yield` in `waitForEvent`, which effectively waits until the event listener is registered and it's safe to return control to the caller. 3. We do actions to trigger the event. 4. We call `generator.next()` to finish the logic after the `yield` in `waitForEvent` so that the generator is exhausted and we wait for the event or a timeout. This should make sure that we always register the event listener before triggering the event, but because we shouldn't miss events anymore we can also remove the retry logic for pasting.
- Loading branch information