Prior to IE7 the following code was a nice way to simulate a pause without stopping the thread that was used by the browser to render elements on a page:
function pause(nMilleseconds)
{
var dialogScript =
'window.setTimeout(' +
' function () { window.close(); }, ' + nMilleseconds +
');'; var result = window.showModalDialog('javascript:document.writeln('
+ '"<script>' + dialogScript +
'</script>")');
}
This was a widely known method, and has since been "fixed" in IE7 as it was identified by MSFT as a vulnerability.
Does anyone know any tricks to mimic this in IE7? Or, specific to my implementation, another way to allow the browser to render animated GIFs while waiting for a
synchronous XMLHttp request.
I did not miss the sync part. The sync request has some issues that are annoying. The one is the locking of the browser. I really do not think that there will be a work around since IE fixed thsi so called whole. I have tried a bunch of things in the past
such as the wonderful iframe with the image pop ups and so forth. Seems to run into more issues with the solutions. Plus the sync request has issues to depending on what browser you are dealing with.
I personally will never try to use a sync request. Even though they are in the application I just inherited at my new job. Been working to remove them. Pain in the (__!__). I also have issues in my application of a for loop locking up annimated gifs when
it processes large datasets. Sucks!
I always try to get around issues with using asyn and doing the "lightbox" type of effect where I throw up a layer on the page and set the opacity of it to 75% so the controls show through and rely on the OO JavaScript to handle the call back as if it were
async. I know that this solution rather sucks so does trying to do any of the other hacks to get an annimation running.
I wish I had a magic wand to make it work. Hopefully someone knows a hack that can get around the new IE7 fix. [Did this ever work with Mozilla/Firefox?]
Eric
{Note to anyone that got here with for loops stoopping annimations - look into setTimeouts for loops instead of the normal for and while, yes it runs slower, but no lock ups}
I'm in a similar situation as far as inheriting some interesting architecture. Basically, I have a bundle whose members need to wait for the response from the request prior before proceeding. There is a notion of "bundling" in the handler "class" that
is half baked that might help me convert this particular view to async, however my user base (all IE) is converting to 7 very soon.
I thought about showing the GIFs in an iFrame then doing hard pauses, is this what you were refering to as being buggy?
JoshStodola - I appreciate your posts, however, unless I'm misunderstanding them, you seem to be distracted by the animated GIF in my implementation. The core issue is pausing without using the thread that is used by the browser for a particular instance
of a document. The pause or wait should happen regardless of any rendering that might be occuring on a page.
Does anyone know any tricks to mimic this in IE7? Or, specific to my implementation, another way to allow the browser to render animated GIFs while waiting for a
synchronous XMLHttp request.
I guess I concluded this was the core problem you are having...
sagesmith
Member
132 Points
58 Posts
javascript wait on a separate thread in IE7
Jun 12, 2007 05:54 PM|LINK
Prior to IE7 the following code was a nice way to simulate a pause without stopping the thread that was used by the browser to render elements on a page:
function pause(nMilleseconds){
var dialogScript = 'window.setTimeout(' + ' function () { window.close(); }, ' + nMilleseconds + ');'; var result = window.showModalDialog('javascript:document.writeln(' + '"<script>' + dialogScript + '</script>")');}
This was a widely known method, and has since been "fixed" in IE7 as it was identified by MSFT as a vulnerability.
Does anyone know any tricks to mimic this in IE7? Or, specific to my implementation, another way to allow the browser to render animated GIFs while waiting for a synchronous XMLHttp request.
A1ien51
All-Star
29503 Points
5718 Posts
Re: javascript wait on a separate thread in IE7
Jun 13, 2007 03:34 AM|LINK
Why don't you change over to a Async request. You can easily throw up a layer on top if the page with an animation saying it is running.
Eric
sagesmith
Member
132 Points
58 Posts
Re: javascript wait on a separate thread in IE7
Jun 13, 2007 02:46 PM|LINK
Thank you for the response. I guess I should have underlined the "synchronous" part. Italics didn't block an obvious non-answer to my problem.
sagesmith
Member
132 Points
58 Posts
Re: javascript wait on a separate thread in IE7
Jun 13, 2007 03:07 PM|LINK
by the way, great book Eric! It is the AJAX bible in our shop.
JoshStodola
Star
13736 Points
3177 Posts
Re: javascript wait on a separate thread in IE7
Jun 13, 2007 03:35 PM|LINK
I guess instead of an animated GIF you could try a Javascript-based animation. Like a simple trailing period animation.
I use this one and my clients love it: http://scriptasylum.com/background/xp_progress/xp_progress.html
Hope this helps!
A1ien51
All-Star
29503 Points
5718 Posts
Re: javascript wait on a separate thread in IE7
Jun 13, 2007 03:35 PM|LINK
I did not miss the sync part. The sync request has some issues that are annoying. The one is the locking of the browser. I really do not think that there will be a work around since IE fixed thsi so called whole. I have tried a bunch of things in the past such as the wonderful iframe with the image pop ups and so forth. Seems to run into more issues with the solutions. Plus the sync request has issues to depending on what browser you are dealing with.
I personally will never try to use a sync request. Even though they are in the application I just inherited at my new job. Been working to remove them. Pain in the (__!__). I also have issues in my application of a for loop locking up annimated gifs when it processes large datasets. Sucks!
I always try to get around issues with using asyn and doing the "lightbox" type of effect where I throw up a layer on the page and set the opacity of it to 75% so the controls show through and rely on the OO JavaScript to handle the call back as if it were async. I know that this solution rather sucks so does trying to do any of the other hacks to get an annimation running.
I wish I had a magic wand to make it work. Hopefully someone knows a hack that can get around the new IE7 fix. [Did this ever work with Mozilla/Firefox?]
Eric
{Note to anyone that got here with for loops stoopping annimations - look into setTimeouts for loops instead of the normal for and while, yes it runs slower, but no lock ups}
sagesmith
Member
132 Points
58 Posts
Re: javascript wait on a separate thread in IE7
Jun 13, 2007 04:32 PM|LINK
I'm in a similar situation as far as inheriting some interesting architecture. Basically, I have a bundle whose members need to wait for the response from the request prior before proceeding. There is a notion of "bundling" in the handler "class" that is half baked that might help me convert this particular view to async, however my user base (all IE) is converting to 7 very soon.
I thought about showing the GIFs in an iFrame then doing hard pauses, is this what you were refering to as being buggy?
JoshStodola
Star
13736 Points
3177 Posts
Re: javascript wait on a separate thread in IE7
Jun 13, 2007 06:35 PM|LINK
Take a look at this post from Rick Strahl's Web Log, and read the comments too:
http://west-wind.com/WebLog/posts/1227.aspx
sagesmith
Member
132 Points
58 Posts
Re: javascript wait on a separate thread in IE7
Jun 13, 2007 06:51 PM|LINK
JoshStodola - I appreciate your posts, however, unless I'm misunderstanding them, you seem to be distracted by the animated GIF in my implementation. The core issue is pausing without using the thread that is used by the browser for a particular instance of a document. The pause or wait should happen regardless of any rendering that might be occuring on a page.
JoshStodola
Star
13736 Points
3177 Posts
Re: javascript wait on a separate thread in IE7
Jun 13, 2007 06:55 PM|LINK
I guess I concluded this was the core problem you are having...