这个问题与Javascript 事件处理和流控制有关，但它超越了一步。仍未回答的问题是：当触发事件并将控制权返回给浏览器时，浏览器是否可以决定首先处理其他事件（由其他脚本或用户操作触发）（A），还是它总是直接处理我的事件（乙）？
这个问题很重要，因为在 (B) 的情况下，您可以相信在触发事件和事件处理程序之间没有任何变化，而 (A) 则不提供任何保证。
我的第一个猜测是 (B)，stopPropagation() 和 preventDefault() 还能如何工作？但是再想一想，这并不是确凿的证据。
这个问题的真实例子。我正在修改一个富文本编辑器（你好），我希望它具有以下规格：
- 单击可编辑文本 (#txt) 将激活编辑器，单击外部 #txt 将禁用它。你好在#txt 上使用模糊和焦点事件来实现这一点。
- 激活编辑器会打开一个工具栏，工具栏上的 mousedown（但不是按钮上的）将设置一个标志，以防止 #txt 上的模糊事件停用编辑器。工具栏将焦点返回到#text。
- 工具栏按钮上的 mousedown 也应该防止停用编辑器，但它应该首先等到单击事件，执行其操作，然后将焦点返回到 #txt。一些动作是即时的（粗体或斜体），而另一些则需要额外的用户输入（从下拉列表中选择）。
- 其中一些按钮会打开一个对话框。
- ...而且我希望所有这些元素（编辑器、工具栏、对话框）都是模块化的并且易于扩展。
现在在大多数情况下，当您关闭对话框时，您希望焦点返回到#txt。但是如果打开了一个对话框并且您单击页面上的其他位置，编辑器将关闭并调用工具栏，包括要关闭的对话框。如果在这种情况下对话框将焦点返回给编辑器，它将再次激活编辑器。
据我现在了解，事件处理顺序至少是确定性的。某些事件不可能延迟，而其他事件处理得更早。这就是“同步”的含义。当然，加载文件之类的事件除外。
从程序组件的角度来看，比如对话框，情况可能非常不可预测。它可以将处理程序绑定到打开事件，然后调用 dialog("open")，但调用和处理程序之间可能发生任何事情，只要因为编辑器在同一事件上有一个事件处理程序。
所以我的结论是 1）是的，它是可以预测的，但是 2）它需要一个复杂的架构来实现它。