避免浏览器中涉及 Ajax 事件的弹出窗口阻止的最佳实践
我知道这听起来可能与 SO 上的几个问题类似，但不知怎的，它们并没有以任何最佳实践说服我。
现在我知道，在使用 AJAX 时，这是一个非常简单的建议，永远不要选择同步 XHR。但是，如果 XHR 是某些验证标准的一部分，如果成功，则必须打开一些弹出窗口，该怎么办？当异步 XHR 被调用时，用户事件就结束了。如果浏览器做得很好，原本打算在回调中打开的弹出窗口将永远不会发生。
在这种情况下，应该有什么好的解决方法可以满足最佳实践。
我读过的一种干净的解决方案是立即打开弹出窗口并更改其在回调中的行为。现在，这当然可以与需要保留直到我们进入回调的额外状态一起使用。还有比这更好的解决方案吗？或者，如果不会造成太多麻烦，理智的人应该坚持使用同步 XHR 吗？
I know this might sound similar to a few questions on SO already, but they somehow don't convince me with any best practice.
Now I know, its a pretty straightforward advice while using AJAX, never (ever) go for Synchronized XHR. But what if that XHR is part of some validation criteria which if succeeds has to open some popups. The moment the asynch XHR is invoked, the User Event has ended. The Popups that were intended to open in the callback will never happen if the browser is doing its job well.
What should be nice workaround that might settle for best practice in such scenario.
One clean solution that I've read is to open the popups right away and change their behavior in the callback. Now this may work ofcourse with extra state that needs to retained till we enter the callback. Is there a better solution out there than this? Or should the saner minds stick to Synchronized XHR if its not causing too much trouble?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当我看到你的问题标题时，这就是我的答案。
将回调声明为创建弹出窗口的函数内的闭包。它将继承所有状态并且浏览器不会锁定。
That was going to be my answer when I saw the title of your question.
Declare the callback as a closure within the function that creates the pop-up. It will inherit all the state and the browser won't lock up.