通过

on calling refresh during onResize

  • 项目

From time to time I have come across web sites that do something like this:

<body onResize=“document.execCommand('Refresh')”> ... </body>

Generally this is done so the page can redo all of the necessary layout calculations for the new size it is being constrained to. This leads to a lot of useless page reloads as the user drags the window around. Really complex pages could have quite a perf impact on the machine. 

Of course with XP SP2 there is an additional concern: if the page automatically launches a download, or tries to install an ActiveX control, or automatically launches a pop-up window the information bar will appear at the top of the page. To make room for the information bar, the mshtml window will be resized. With the above HTML, the appearance of the information bar will cause the page to reload. This will start the cycle all over again, leading to infinite page reloading. It is better to have layout methods that can be called directly, instead of being lazy and just refreshing the page. 

Another good practice is to not assume that window.open() will always succeed, but instead check the return value for null before using it. If it returns null, your script should handle it. There has always been the possiblity of failure while creating a new window.

Doc links: execCommand onResize window.open

Comments

  • Anonymous
    April 20, 2004
    Why refresh a page as a response to client side events? Because that's what Asp.Net encourages with its server side event handling. But they call it Post back, not a refresh :)
  • Anonymous
    April 20, 2004
    Netscape Navigator used to work this way; they couldn't dynamically render so they would re-draw each time you resized the window... and I'm pretty sure they would REQUEST THE PAGE AGAIN!

    This caused weird problems if the web page was the result of an operation that had some side-effect (such as adding entries to a database or sending off e-mail messages). I once had to debug a problem at a customer site where they got duplicate e-mails sent out to customers from their web-based system. Of course I went to the site and, using IE, was unable to repro it even after debugging through client code, server code (ColdFusion... shudder) etc.

    Went to visit one of the users for which it re-pro-ed, and they fired up Navigator, hit the page, and then PRINTED OUT THE RESULT PAGE. Instantly I knew what the problem was -- printing in Navigator re-submitted the request to the server, which sent out all the mails again. Moral here is that GET requests should not have side-effects... but I didn't write the original code ;-)
  • Anonymous
    June 13, 2009
    PingBack from http://barstoolsite.info/story.php?id=1487