WebExtensions/Implementing APIs out-of-process: Difference between revisions

Jump to navigation Jump to search
(Add more practical documentation)
Line 218: Line 218:
=== Timing issues ===
=== Timing issues ===


Pay attention when order of execution is important in APIs.
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 matches the order of API invocations in the child.
* The order of running API implementations in the parent is guaranteed to match the order of API invocations in the child.
* The second 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.
* 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.
44

edits

Navigation menu