dcsimg
www.webdeveloper.com
Results 1 to 4 of 4

Thread: IE8 not rendering as expected

  1. #1
    Join Date
    Aug 2010
    Location
    Santa Rosa, CA
    Posts
    3

    IE8 not rendering as expected

    I’m trying to add some simple display features to a web application and am running into some unexpected IE8 behavior. Basically, the app runs some database retrieval from the server using Ajax techniques, and during that time (say, 30 seconds), I want to just give the user a clue as to what’s going on. It could be as simple as a wait cursor. More interesting, I prefer to unhide a div with an animated loading icon, then hide it again when loading is complete.

    This all works as intended in Firefox (or EOMB), but in IE8 you just never see the display changes. It’s as if IE8 does not bother to render in response to changes in the DOM tree when there is background activity. Here’s a trivial JavaScript example:

    document.body.style.cursor = 'wait';
    goDoAjaxStuff();
    document.body.style.cursor = 'default';

    or:

    document.getElementById('loader').style.display = "block"; // unhide the div
    goDoAjaxStuff();
    document.getElementById('loader').style.display = "none"; // hide it again

    I tried emitting headers to turn off aggressive caching from PHP – no help. I’m encouraging IE8 mode (good or bad?).

    <meta http-equiv="X-UA-Compatible" content="IE=IE8" >

    But as long as those XHR gets are going on in the background, the display never changes. Does anyone have any suggestions as to ways to work around this? I can code around it, but it’s a lot of work to restructure the application. Any suggestions appreciated.

  2. #2
    Join Date
    Dec 2005
    Posts
    2,984
    There's (usually) always a return function that tells the XHR (XML HTTP Request) what to do when it's finished.

    Stick your ending code (the ....style.display = 'none' or ....style.cursor = 'default') in this function, rather than after your goDoAjaxStuff() call.

    Chances are very likely you're making an asynchronous request. In which case, Javascript sends the request off and while it's waiting for a response, continues to execute in the proper procedure. In other words, as soon as the request is sent via goDoAjaxStuff() (but before it is complete) your browser will process the instructions on what to do after your goDoAjaxStuff() line of code.

    I'm surprised that this 'works' in any browser as you would expect it to. You don't actually say what the functionality is in FF/Chrome/Safari/Opera/etc....chances are it's the same as IE8.

  3. #3
    Join Date
    Aug 2010
    Location
    Santa Rosa, CA
    Posts
    3
    As is often my habit, I probably oversimplified the problem description a bit. It’s a big, complicated app.

    I am trying to turn on an indicator at the start of a process and turn it off at the end. The process involves retrieving data from a database via the web server. The problem is not turning the indicator off – I need to get it to turn on. Either it never turns on in the first place, or it turns off too soon.

    Due to the requirements of this part of the application, all XHR gets are synchronous. After the data is retrieved, it is manipulated a bit and stored before issuing the next request.

    When there is a single XHR, I do in fact try to turn it off in the load callback. Always a fine idea.

    However, in this case there are multiple XHRs – sorry, it’s just the way this application has to be structured. So turning it off in the load callback would really turn it off too soon, because it would be turned off on the first callback, hardly what I want. I need to wait until the last load completes, and then turn it off. I know when the last XHR is completed and when it has finished manipulating its data on the client side, so it is time to move on – and hide the indicator.

    My (possibly unreasonable) expectation was that any change to the DOM tree would cause the display to be updated instantly. So turning on the indicator should (for example) cause the loader div to be unhidden right away. And when I am finished with the load process, I would turn it off by hiding the div.

    I did mention that this is the exact behavior I observe in Firefox – maybe I was not clear enough about that. I have now done some additional testing, and I can report that it works as I expected in Firefox and Opera, and does not work in IE8 and Safari. I don’t have Chrome handy.

    So a better attempt at pseudo-code might be:

    function goDoAjaxStuff() {
    for (var i=0; i<workingList.length; i++) {
    doSynchronousXHR(i);
    doSomethingWithTheResult();
    }
    }

    document.getElementById('loader').style.display = "block"; // unhide the div
    goDoAjaxStuff();
    document.getElementById('loader').style.display = "none"; // hide it again

    Given that all requests are synchronous, I'd still like to know why works in only some browsers and not others.

  4. #4
    Join Date
    Aug 2010
    Location
    Santa Rosa, CA
    Posts
    3
    You're not giving us enough info to allow us to be helpful, but it seems to work much the same in IE8 and Firefox.

    As it turns out, my problem is pretty much due to a “screen vs. script” priority issue. Here’s a little experiment.

    I put in a timer using setTimeout() to hold off retrieval for half a second. And, lo and behold, now IE does display the animated icon. But after half a second, the animated icon freezes. There’s a button that has been revealed, but when you click on it, nothing happens. Thirty seconds later when the script has finished, you get the response to the button click event (just displays some help text in one of the divs).

    So it is clear that IE is giving priority to the script, and deferring response to events (like onclick) and on-screen animation.

    Firefox works completely the opposite. That is, animation continues while the script runs, and button clicks are responded to right now – not after the script finishes. So Firefox is giving priority to the UI, and running the script more as a background task – as I intended.

    It’s pretty clear this is not something you can depend on. I did try Chrome, and it works much as IE. There is no consistency in how browsers prioritize things.

    So I simply coded around it to introduce a small delay (1/10 second seems enough) between retrievals, and now things work as I want in all browsers. This also explains why a number of other things I was doing (like using a jQuery UI slider as a progress bar) don’t work as expected in IE – because IE always gives priority to the running script, not the UI.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles