这个问题与Javascript事件处理和流程控制相关,但它比那个问题更进一步。仍未回答的问题是:当触发事件并将控制权返回给浏览器时,浏览器是否会决定先处理其他事件(由其他脚本或用户操作触发)(A)或始终直接处理我的事件(B)?
这个问题很重要,因为如果是(B),您可以依赖于在触发事件和事件处理程序之间没有任何更改,而(A)则不提供任何保证。
我的第一个猜测是(B),否则如何使用stopPropagation()和preventDefault()呢?但重新考虑后,并没有硬性证据。
这个问题的一个现实例子。我正在修改一个所见即所得的富文本编辑器(hallo),我希望它具备以下规格:
- 单击可编辑文本(#txt)将激活编辑器,并在单击#txt之外时将其停用。 hallo使用#txt上的blur和focus事件来实现此功能。
- 激活编辑器会打开工具栏,工具栏上的mousedown(但不是按钮)将设置一个标志,以防止#txt上的模糊事件停用编辑器。 工具栏将使#text重新获得焦点。
- 在工具栏按钮上按下鼠标也应该防止停用编辑器,但它应该等待点击事件,执行其操作,然后返回焦点到#txt。 一些操作是立即执行的(加粗或斜体),而另一些需要额外的用户输入(从下拉列表中选择)。
- 其中一些按钮会打开对话框。
- ...我希望所有这些元素(编辑器、工具栏、对话框)都是模块化的且易于扩展。
现在,在大多数情况下,当你关闭一个对话框时,你希望焦点返回到 #txt。但是,在打开对话框并单击页面上的其他地方的情况下,编辑器将关闭并调用工具栏,包括要关闭的对话框。在这种情况下,如果对话框返回焦点到编辑器,它会再次激活编辑器。
就我现在的理解而言,事件处理顺序至少是可确定的。不可能出现某些事件延迟处理而其他事件先被处理的情况。这就是所谓的“同步”。当然,像加载文件这样的事件是例外。
从组件程序的角度来看,比如对话框,情况可能相当不可预测。它可以绑定一个处理程序到打开事件,然后调用 dialog("open"),但在调用和处理程序之间任何事情都可能发生,即使只是因为编辑器有一个在同一事件上的处理程序。
因此,我的结论是1)是可预测的,但 2)需要一个复杂的体系结构来实现这一点。
openDialog()
和doThing()
函数中添加几个console.log()
语句进行测试这不是很简单吗? - lanzzopenDialog
的代码是什么?你没有在同一节点集上注册两个click
事件,所以我不认为你会得到(B)
。 - Ja͢ck