应用错误收集

这个问题与Javascript event handling and flow control有关，但它超越了一步。仍然没有答案的问题是：当一个事件被触发并且控制权返回给浏览器时，浏览器是否可以决定先处理其他事件（由其他脚本或用户操作触发）（A），或者它是否总是直接处理我的事件（B）？

Does javascript event handling occur outside (A) or inside (B) the program flow? 这个问题很重要，因为在情况（B）中你可以依赖于在触发事件和事件处理程序之间没有任何改变的事实，而（A）不给出任何保证。

我的第一个猜测是（B），还有什么可以stopPropagation（）和preventDefault（）工作？但是再给它一点思考，这并不是确凿的证据。

这个问题的现实例子。我正在修改一个富文本编辑器（hallo），我希望它有这些规范：

单击可编辑文本（#txt）将激活编辑器，单击#txt外部将停用它。 hallo在#txt上使用模糊和焦点事件来实现这一目标。
激活编辑器会打开一个工具栏，工具栏上的moused（但不在按钮上）将设置一个标志，以防止#txt上的模糊事件停用编辑器。工具栏将焦点返回到#text。
mousedown也可以防止停用编辑器，但它应该等到click事件，执行其操作然后将焦点返回到#txt。有些操作是立即的（粗体或斜体），而其他操作需要额外的用户输入（从下拉列表中选择）。
其中一些按钮会打开一个对话框。
...我希望所有这些元素（编辑器，工具栏，对话框）都是模块化的并且可以轻松扩展。

现在，在大多数情况下，当您关闭对话框时，您希望焦点返回到#txt。但是如果打开对话框并单击页面上的其他位置，编辑器将关闭并调用工具栏，包括要关闭的对话框。如果在这种情况下对话框将焦点返回到编辑器，它将再次激活编辑器。

据我所知，事件处理顺序至少是确定性的。某些事件可能会延迟，而其他事件则会提前处理。这就是'同步'的含义。例外情况当然是加载文件等事件。

从程序组件的角度来说，说对话框，情况可能非常难以预测。它可以将处理程序绑定到open事件，然后调用dialog（“open”），但是在调用和处理程序之间可能发生任何事情，只是因为编辑器在同一事件上有一个事件处理程序。

所以我的结论是1）是的，它是可预测的但是2）它需要一个复杂的架构来实现它。