如果用户单击一个链接，然后快速单击另一个链接，则不会触发第二个链接的 onclick。我们如何避免这种情况？
对标题表示歉意，我发现很难简洁地定义我的问题，这是我能做的最好的事情。如果有人想编辑它以添加更好的标题，请成为我的客人。
无论如何，问题。我们的网页上允许用户删除某些内容。他们通过单击删除链接来完成此操作，看起来像这样：
<a href="http://localhost/a/path/remove-thing.html?ID=42" onclick="return confirm('Are you sure you want to remove this thing?');" >Remove this thing!</a>
现在，显然，通常当用户单击该链接时，他们会看到一个 javascript 确认框，要求他们确认是否要删除该内容。如果他们单击 ccel，则 onclick 事件为 false，因此不会发生删除；如果他们点击“确定”，那么就可以了。
我的问题是，如果用户单击页面中的另一个链接（到任何地方），然后在加载第一个页面之前快速单击删除链接，则 JavaScript 永远不会被触发，但事物被删除- 当他们点击“删除这个东西！”时他们触发了该 URL，而不是他们最初单击的 URL。有办法避免这种情况吗？我们的确认操作是否“错误”？我认为这与浏览器在准备呈现新页面时单击第一个链接时关闭 JavaScript 检查有关，但在页面消失之前仍然接受 URL 的更改...
（这已是在 Firefox 3.6 中进行了测试并确认了该问题，尚未测试其他浏览器。）
Apologies for the title, I found it hard to define my question succintly and that was the best I could do. If someone wants to edit it to add a better title then please, be my guest.
Anyway, the question. We have on our webpage the capability for users to delete something. They do this by clicking on a delete link, something that looks something like:
<a href="http://localhost/a/path/remove-thing.html?ID=42" onclick="return confirm('Are you sure you want to remove this thing?');" >Remove this thing!</a>
Now, obviously, normally when the user clicks on that link they get a javascript confirm box which asks them to confirm that they want to delete the thing. If they click cencel, the onclick event is false and so the delete doesnt happen; if they click okay then it does.
My problem is that if the user clicks on another link in the page (to anywhere), then quickly clicks on the delete link before the first page loads, the javascript never gets fired, but the thing is deleted - when they clicked on "Remove this thing!" they fired off that URL instead of the one they originally clicked. Is there a way to avoid this? Are we doing the confirm 'wrong'? I assume it has something to do with the browser shutting off the javascript checking when you click the first link as it prepares to render a new page, but then still accepting a change in URL before the page has gone...
(This has been tested in Firefox 3.6 and confirmed a problem there. No other browsers tested yet.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
解决此问题的一种方法是：
这样即使没有 javascript，它也可以工作，并且应该有望消除您的问题
编辑
如果 js 始终存在，您可以始终将默认链接设置为空，并在确认后重定向用户
one way around this which would degrade a bit more gracefully would be something like:
this way it works even without javascript, and should hopefully eliminate your issue
EDIT
if js will always be present, you can always have the default link be empty, and redirect the user after confirmation
你确实遇到了一些问题。我认为你最好采取渐进增强方法。
如果您的用户没有 JavaScript，会发生什么情况？我知道人们很少关闭 JavaScript，但这仍然是一个值得考虑的有用的事情。如果没有 JavaScript，人们将在未经确认的情况下删除项目。
您最好链接到一个删除表单，询问“您确定要删除 X 吗？”并有“删除”和“取消”按钮。表单提交或按取消后，您可以将其发送回原始页面。 *
现在进行渐进增强：将单击事件处理程序附加到“删除”链接，该链接会拉入“您确定吗？”通过 AJAX 形成或从头开始构建。让表单替换删除链接。如果他们点击“删除”按钮，只需像以前一样提交表单即可。如果他们单击“取消”，则无需重新加载页面 - 只需删除表单并恢复原始的“删除”链接即可。
* 另外，请确保该表单是后表单并且具有 CSRF 保护。如果您不了解 CSRF 攻击，请务必阅读它们。
You're really having a couple of problems. I think you would be better off taking a progressive enhancement approach.
What happens to your users if they don't have the JavaScript? I know that people rarely turn off JavaScript, but it's still a useful thing to consider. Without JavaScript, people will be deleting items without confirmation.
You're better off linking to a delete form that asks "Are you sure you want to delete X?" and has "Delete" and "Cancel" buttons. After the form submits or they press cancel, you can send them back to the original page. *
Now for the progressive enhancement: attach a click event handler to the "delete" link that pulls in the "are you sure?" form via AJAX or builds it from scratch. Have the form replace the delete link. If they click the "Delete" button, just submit the form as before. If they click cancel there's no need to reload the page - just remove the form and restore the original "delete" link.
* as an aside, make sure the form is a post form and that it has CSRF protection. If you don't know about CSRF attacks, definitely read up on them.