Javascript中阻塞了哪些方法? [英] What methods are blocking in Javascript?

查看:79
本文介绍了Javascript中阻塞了哪些方法?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我试图在Javascript中覆盖标准的 confirm()方法(制作一个漂亮的用户界面和东西)。我已经阅读了100篇无法完成的帖子,但我不想放弃,直到我给它一个公平的镜头。 :)

I'm trying to override the standard confirm() method in Javascript (make a nice UI and stuff). I've read a 100 posts that it "can't be done", but I don't want to give up until I have given it a fair shot. :)

所以,真正的问题当然是 confirm()方法必须阻止所有javascript执行,直到用户选择一个选项。那么,Javascript中有哪些阻塞行为的方法呢?我已经能够拿出5:

So, the real problem is of course that the confirm() method must block all javascript execution until the user selects an option. So, what are the methods in Javascript that have blocking behavior? I've been able to come up with 5:


  • alert() - 不适合我,因为它显示了自己不需要的用户界面;

  • confirm() - 与<$ c相同的问题$ c> alert();

  • 无限循环 - 即使是现代浏览器也会疯狂地消耗CPU并显示停止javascript?几秒后提示;

  • XmlHttpRequest 在同步模式下 - 排序,但它涉及服务器......

  • showModalDialog() - 很好,但我需要一个特定的设计,还有一些浏览器兼容性要求......

  • alert() - does not suit me, because it displays an unwanted UI of its own;
  • confirm() - the same problem as alert();
  • infinite loop - even modern browsers will eat away CPU like crazy and display a "stop javascript?" prompt after a few seconds;
  • XmlHttpRequest in synchronous mode - sort of, but it involves server...
  • showModalDialog() - nice, but I need a specific design, plus there are some browser compatibility requirements...

我到目前为止最好的方法是使用提示创建< iframe> (然后获取它自己的javascript执行线程)并使用 XmlHttpRequest 进行阻止,直到用户在< iframe> 中选择了一个选项。不幸的是,这涉及在服务器之间反复传递结果,我想让这个100%客户端。此外,它在打开对话框时占用服务器线程,并且可能存在一些适用于浏览器的特定ajax超时。

The best approach I have so far is to create an <iframe> with the prompt (which then gets its own javascript execution thread) and block with XmlHttpRequest until the user has selected an option in the <iframe>. Unfortunately this involves passing the result forth and back between the server, and I'd like to make this 100% client-side. Also, it ties up a server thread while the dialog is opened, and there might be some browser-specific ajax-timeouts that apply.

任何人都可以想到任何其他Javascript阻止执行可能(ab)用于达到预期效果的方法?

Can anyone think of any other Javascript methods that block execution which might be (ab)used to achieve the desired effect?

推荐答案

不,它可以'完成是有充分理由的。页面中任意的,自定义样式的用户交互始终是异步的(基于事件的),因此不适用于任何类型的阻塞行为(只会发生阻止无限循环的事件)在无限循环结束后)。

No, it can't be done for a good reason. The arbitrary, custom-styled user interaction in the page is always asynchronous (event-based), and therefore does not work with any type of blocking behaviour (the event that would stop the infinite loop would only occur after the infinite loop has finished).

你提到的所有阻塞方法都在与页面不同的环境中进行用户交互 - 警报 / 确认 / 提示由浏览器控制的弹出窗口,由<加载的不同页面code> showModalDialog - 当第一个被冻结时,该环境需要能够获得焦点。

All those blocking methods that you mentioned do their user interaction in a different environment than the page - the alert/confirm/prompt popups controlled by the browser, the different page loaded by the showModalDialog - and that environment would need be able to gain focus while the first is frozen.

创建像这样可靠的设置是很困难的。但是,您可以尝试几乎每个 javascript功能(不涉及异步回调),因为默认情况下所有JS操作都是同步的。如果你想进一步试验,我建议你看看那些处理不同DOM环境的方法( window.open document.write iframe.contentWindow 跨框架访问)以查看是否可以获取其中任何一个来生成并行运行的第二个环境可靠。

Creating a setup like this reliable is difficult enough. However, you could try almost every javascript functionality (that does not involve async callbacks), as all JS operations are synchronous by default. If you want to further experiment, I would suggest to look at those methods that deal with different DOM environments (window.open, document.write, iframe.contentWindow cross-frame-access) to see whether you can get any of these to spawn a second environment which runs in parallel reliably.

这篇关于Javascript中阻塞了哪些方法?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆