The relative execution order of chrome.tabs.executeScript
is not documented, but it extremely likely that you can rely on its order.
Behind the scenes, executeScript
does the following:
- The JavaScript code invokes native code on the UI thread (source code).
- If the extension is allowed to execute code in the tab, the UI thread sends the message with execution details to the renderer process over IPC (source code, source code).
- When the renderer receives the message (source code), it executes the code in the web page (source code). When the script has finished executing in all pages, the renderer sends a message back to the extension process (source code).
- The message is received by the extension process, and the callback (JavaScript) is invoked (source code).
Note that everything in this flow is synchronized: JavaScript is single-threaded, so the code is synchronously processed. The native code that handles the call runs synchronously as well, and the messages in IPC are also synchronized.
chrome.tabs.executeScript
is asynchronous in the sense that it does not block the extension process until the code in the tab has finished (i.e. after calling chrome.tabs.executeScript
, it immediately returns, ready to execute the next statement in your code). That is nice, because you don't want that your extension process gets frozen because of an alert
dialog in the executed content script.
This answer refers to code at trunk (Chrome 36), but I believe that it will remain accurate in the future, because there is no reason to alter the implementation that intentionally mixes the relative order of the messages. One of the most realistic ways of mixing up messages is to make native code asynchronous and have different execution paths (I reckon that this does not happen).