44
edits
(Add more practical documentation) |
(→Timing issues: Clarify) |
||
Line 218: | Line 218: | ||
=== Timing issues === | === Timing issues === | ||
There are subtle timing issues related to the order of execution of asynchronous APIs. If in doubt, design the API in such a way that the order of execution is not relevant. Failing to recognize the problems will may result in intermittent tests. | |||
* The order of running API implementations in the parent | * The order of running API implementations in the parent is guaranteed to match the order of API invocations in the child. | ||
* | * An API call must ''not'' unconditionally assume that the previous API call has finished. This is because the previous API call may have an asynchronous implementation. | ||
* There is a subtle timing issue with event registrations that is especially visible when the add-on controls the trigger of the event and registers an event in a callback. Async APIs that trigger events may trigger the events before the callback is called. This is especially important in unit tests. For instance, <code>tabs.create</code> creates a tab which triggers the <code>tabs.onUpdated</code> event. If the add-on registers calls <code>tabs.onUpdated.addListener</code> in the callback, then it is possible that the onUpdated event has fired before the listener registration is processed by the parent. Due to the fact that the event listeners are shared, if a ''(different)'' listener is registered before the <code>tabs.create</code> call, the result may be different: When the "onUpdated" event is triggered in the parent, the event is fired and (asynchronously) sent to the child. Meanwhile the callback was invoked, the event was registered and the new event listener is also invoked. | * There is a subtle timing issue with event registrations that is especially visible when the add-on controls the trigger of the event and registers an event in a callback. Async APIs that trigger events may trigger the events before the callback is called. This is especially important in unit tests. For instance, <code>tabs.create</code> creates a tab which triggers the <code>tabs.onUpdated</code> event. If the add-on registers calls <code>tabs.onUpdated.addListener</code> in the callback, then it is possible that the onUpdated event has fired before the listener registration is processed by the parent. Due to the fact that the event listeners are shared, if a ''(different)'' listener is registered before the <code>tabs.create</code> call, the result may be different: When the "onUpdated" event is triggered in the parent, the event is fired and (asynchronously) sent to the child. Meanwhile the callback was invoked, the event was registered and the new event listener is also invoked. |
edits