[Stratoscope]

> [Wow Alert] overrides the existing alert function.

That is an absolutely terrible idea. It overrides alert() but doesn't - and can't - duplicate its blocking behavior.

I'm not criticizing you for liking the idea! I can see its appeal myself. I'm criticizing Wow Alert for letting a nifty idea result in bad sofware design.

https://github.com/al0p/wow-alert/blob/b3224bc34fea6a49aac2d...

Their version of window.alert() returns immediately after setting up the alert window and actions - because that's all it is capable of.

If you just drop this into existing code without inspecting each and every alert() call to make sure it doesn't rely on the blocking - both in your own code and every library you use - you will definitely break things.

Far better to leave alert() alone and make this a separate function with its own name.

[aidanhs]

> It overrides alert() but doesn't - and can't - duplicate its blocking behavior.

If you really wanted to, I think you could set up an endpoint on your server to be long polled with synchronous XHR in a while loop, while you set up the popup in an iframe. When the popup is clicked, you send a notification to the server so the next synchronous request returns 200 and you dispose of the iframe.

On searching, I discover someone else has had this crazy idea already - http://stackoverflow.com/questions/16934667/what-methods-are...

[Stratoscope]

I like that kind of insane creativity!

I'm surprised that the SO poster got the synchronous XHR approach to work. When I did some tests with Chromium last year they seemed to show that an iframe runs in the same thread as its parent window. I wasn't testing XHR though, just animation.

So if you ever do try this out, I would be interested to hear the results. Thanks!

[MasterScrat]

This reminds me of this SO answer. I never understood what the guy was trying to do but people seem to be happy with it?!

http://stackoverflow.com/a/16758230/318557