javascript事件处理是在程序流程内部还是外部发生的?

Car*_*sen 10 javascript event-handling program-flow

这个问题与Javascript事件处理和流量控制有关,但它只是一步之遥.仍然没有答案的问题是:当一个事件被触发并且控制权返回给浏览器时,浏览器是否可以决定首先处理其他事件(由其他脚本或用户操作触发)(A),或者它总是直接处理我的事件(B)?

javascript事件处理是在程序流程之外(A)还是在(B)之外发生的? 这个问题很重要,因为在情况(B)中你可以依赖于在触发事件和事件处理程序之间没有任何改变的事实,而(A)不给出任何保证.

我的第一个猜测是(B),还有什么可以stopPropagation()和preventDefault()工作?但是给它第二个想法,这并不是确凿的证据.

这个问题的现实例子.我正在修改一个富文本编辑器(hallo),我希望它有这些规范:

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

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

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

从程序组件的角度来看,比如对话框,情况可能非常难以预测.它可以将处理程序绑定到open事件,然后调用dialog("open"),但是在调用和处理程序之间可能发生任何事情,只是因为编辑器在同一事件上有一个事件处理程序.

所以我的结论是1)是的,它是可预测的,但2)它需要一个复杂的架构来实现这一点.

dav*_*vin 4

一般来说,事件模型是同步和可重入的,这意味着如果事件处理程序引发另一个事件,第二个事件将同步执行,只有在完成后第一个事件才会继续执行。

这似乎就是您想要描述的内容,在这种情况下(B)是有保证的。

相关来源:http://www.w3.org/TR/DOM-Level-3-Events/#event-flow