0

I have some JQueryUI animation coupled with some Jquery code that addes some html to the page. The html is generated based on data from a JQuery Ajax call.

I thought the freezing of my animations might be from the Ajax call, but from what the question below is saying i'm thinking not:

Why does my spinner GIF stop while jQuery ajax call is running?

I think the issue I am having may be of the same origin, however the question above provides a REASON for the behavior, not a SOLUTION.

Does anyone have a solution?

Community
  • 1
  • 1
kralco626
  • 8,456
  • 38
  • 112
  • 169
  • I should qualify what i mean when I say freezing, it freezes momentarily, and then finished hiding. At some arbitary point in the slideup, the animation will freeze for a second, and then the remaing part of the div will hide without animation and then second div that was just populated with html will slidedown without issue. So it's clear to me that loading of the second div is interfearing with the animation of the second. – kralco626 Apr 13 '11 at 11:01

2 Answers2

0

This article could be of assistance for you.

The key part of the HTML elements is as follows:

<span id='myHiddenDiv' style='display: none'>
  <img src='' id='myAnimatedImage' align='absmiddle'>
</span>
<asp:Button ID="Button1" runat="server" OnClick="Button1_Click" OnClientClick="showDiv();" Text="Search" />

We have a hidden span (it could be a div, if you want it on a new line), and inside this span is our img tag. Next, in the OnClientClick handler of our button, we call the "showDiv();" client script function which looks like so:

<script language='javascript'> 
  function showDiv() 
  {
    document.getElementById('myHiddenDiv').style.display =""; 
    setTimeout('document.images["myAnimatedImage"].src="work.gif"', 200); 
  } 
</script>

This uses the setTimeout method to make the DOM reset the src property of the image after 200ms. The result is that when you press your button that kicks off your long - running method, the image will show and continue animating until the postback returns and the page is reloaded, whereupon the image disappears -- exactly the behavior we want.

Blair McMillan
  • 5,299
  • 2
  • 25
  • 45
  • this is interesting, but in my case I don't have an image. I have some JqueryUI animation that is freezing up. Like if I use .slidUp the div will slip part was up, freeze, then finish hiding. I'm thinking the freezing is comming from adding some html to the page as suggested in the linked question. Do you have any idea how I might fix that? – kralco626 Apr 11 '11 at 12:36
  • @kralco626 if the slide is jumpy check out http://jqueryfordesigners.com/slidedown-animation-jump-revisited/ – redsquare Apr 11 '11 at 12:40
  • @redsquare - I could be wrong, but it seems that the jumpy issue discussed in that article is an issue with the animation itself, another words it happens when simply using the animation, even if nothing else is happening on the page. This is not that case, if the animation is the only thing that is happening than there is no problem. It is only when I am also, while preforming the animation preforming ajax calls and subsequently generating html and adding it to the page. – kralco626 Apr 11 '11 at 13:28
  • @kralco626 - can you try to replicate your issue at jsfiddle.net? Hard to see exactly what you mean without an example hence the guess above! Remember that javascript is single threaded still, so any heavy operation (creation and firing of an xhr) will cause a lag of other running js - especially with ie's slower js engine. – redsquare Apr 11 '11 at 13:30
  • @redsquare - i'll try to get an eamil on jfiddle, but not being sure exactly what the problem is it's difficult to know what code I will have to put on jsfiddle to replicate it. I do do a lot of $("#something").html(some rather large string of html) so maybe like the question i posted says it has to do with the fact that it's busy adding the new html and can't do the animation at the same time. This does not happen on firefox or chrome, so i might just tell my clients that if they don't like the glitch they can get the company to let them use a good browser rather than that ie8 piece of crap – kralco626 Apr 11 '11 at 14:32
  • @kralco626 - Yeh, my understanding of the link above wasn't so much that an animated gif stopped moving, but that IE had trouble rendering *anything* while I was doing large/complex HTML inserts. Try to get a jsfiddle up and running showing the problem (I'd start with animating while trying to insert a *large* amount of HTML). If you can't get that sorted, then I'd putting the `slideUp` in a `setTimeout` function. If that still doesn't work, then I'd try splitting the `.html()` insert up into smaller chunks if possible. – Blair McMillan Apr 12 '11 at 07:59
  • @blair - at the same time that the animation freezes, the ie8 menus also freeze too i think. I made some changes in my code to be more efficient, and the time that the animation freezes is minimal. I should note that chrome handels this beautifully, having perfectly unchoppy animation. – kralco626 Apr 13 '11 at 10:47
  • jsfidde - http://jsfiddle.net/kralco626/2KLHL/ however it does not work. It does not display the effect i'm getting, i tried to use setTimeout to enulate the ajax request returning data during the animation, but it didn't work. I think the correct answer here is to use chomre or firefox, and tell microsoft to fix their browser... – kralco626 Apr 13 '11 at 10:58
  • @kralco626 - The menus freezing confirms that it's IE's single thread JS engine causing the issue. The only way that you'll get it to work "correctly" in IE is to reduce the amount of work that IE needs to do all at once. Can you insert the HTML in smaller chunks? – Blair McMillan Apr 13 '11 at 11:05
  • I could try that, no really good way to do it. I guess I could just arbitrarily break up the html string into sections and insert it that way. – kralco626 Apr 13 '11 at 11:09
  • looks like I actually have ot insert valid html each time, so that wont work. I would have to write some sotra script to parse out the html string and break it up into valid chunks and insert it that way... – kralco626 Apr 13 '11 at 11:28
  • Yeh, unfortunately it has to be valid and you can't break it mid tag, otherwise the browser will just close the tag and when you come to add the rest of the HTML it'll be all broken. Do you have any control over the response provided by the AJAX call? – Blair McMillan Apr 13 '11 at 11:51
  • Ya I do. The Ajax call returns an object and then there are a number of javascript functions that use the information in that object to generate the chunk of html. I would have to rescructure those functions to generate the html in pieces. What I was told in other questions I asked about efficency(i'll see if i can find the question) is that it would be best to manipuate the DOM the least number of times. This is why the html is generated as a string and inserted once. – kralco626 Apr 13 '11 at 12:49
  • http://stackoverflow.com/questions/4594410/most-efficient-way-to-create-form-with-jquery-based-on-server-data – kralco626 Apr 13 '11 at 12:50
  • As a test, can you try returning the HTML directly from the Ajax request and see if IE handles that any better than it having to generate the chunk of HTML. If need be, get the HTML string from FF or something and return that directly. Do you know what I mean? The answer to the other question is correct, however if this test doesn't help at all then you may need an *overall* slower insert, but without the IE freeze (by chunking the HTML somehow). – Blair McMillan Apr 13 '11 at 14:18
0

So I think that there are 3 main "solutions" to this problem; well they are more workarounds.

  1. You can remove the hide animation. Use just .hide() and then use some animation on the show.
  2. You can use the callback method of the hideing animation to then insert the html and show the new div
  3. You can use a different browser. I have only tested on ie8/firefox/chrome; but I would in this case have to suggest chrome as it's ability to do this beautifuly is amazing. While I would normally also suggest firefox, however in this case it's handeling of this sitution is no better than ie8's.

And of course I guess there is a fourth solution, which is to just deal with it.

kralco626
  • 8,456
  • 38
  • 112
  • 169