none
Inline script with included script in iframe freezes IE 7 & 8

    Question

  • I have a particular set of pages which is feezing both newer IE browsers and 
    their debuggers (and probably the older as well).  No error messages: an 
    outright freeze.
    
    Basically, there's a parent .asp page with an iframe.  The iframe's content 
    is generated by a call to a javascript function from the parent and written 
    by document.writes.  The iframe's content is written at page load, and 
    rewritten everytime a selection is made in the parent page, which recalls the 
    function and rewrites the iframe's content using changed variables which both 
    share. 
    
    the iframe's dynamically rendered document contains both inline script (of 
    the form <script type='text/javascript>function foo() {}</script>) and 
    included javascript files (of the form <script src=something.js 
    type='text/javascript'></script>).
    
    evidently this is what freezes the IE browsers. If the iframe content 
    contains both inline and outside javascript files, the browser freezes in the 
    middle of loading the parent page (which, you remember, also produces the 
    iframe content initially).  There is no problem with other browsers' 
    accessing the same content.
    
    Is there something simple I'm missing?  
    
    I have a complete test case: the parent page containing the iframe, the 
    script which puts minimal content into the iframe, and a dummy outside 
    javascript file to be referenced in the iframe content.  This is the problem 
    reduced to its simplest terms, if you want to put it on the server, here it 
    is:
    
    //this is "Something.asp", the parent page.  notice that it is written on 
    the server, but, or course, appears to the browser as html.  It sets up an 
    iframe.  then it calls a function (writesomething() in an outside file: 
    something.js, which provides markup to the iframe...
     
    <%@ LANGUAGE = "JavaScript" %>
     
    <% 
     
    Response.Write("<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01//EN' 
    'http://www.w3.org/TR/html4/strict.dtd'>\r");
    Response.Write("<html lang='en'>\r");
    Response.Write("<head>\r");
    Response.Write("<meta http-equiv='content-type' content='text/html; 
    charset=UTF-8' />\r");
    Response.Write("<meta name='description' content=' ' />\r");
    Response.Write("<meta name='keywords' content=' ' />\r");
    Response.Write("<meta name='Author' content='DA Ward - 
    daward@worldnet.att.net' />\r");
    Response.Write("<meta name='copyright' content='© 2009 DA Ward, Associates' 
    />\r");
    Response.Write("<title>IE 8 Flaw master page</title>\r");
    Response.Write("<style type='text/css'>\r\r");
     
    Response.Write("<style type='text/css'>\r\r");
    Response.Write("body {color:black; font-size:24px; text-align:center; 
    width:980px; height:600px;}\r\r");
    Response.Write("</style>\r\r");
    Response.Write("<Script type='text/javascript' 
    src='something.js'></Script>\r\r");
    Response.Write("<body>\r");
    Response.Write("<div style='float:left; width:980px;'>\r");
    Response.Write("<div style='float:left; width:260px; padding:40px 20px;'>\r");
    Response.Write("This is the server page, which sets markup and calls 
    something.js.<br><br>Something.js writes its own markup into the iframe on 
    the right.<br><br>As it's coded now, the page loads.<br><br>To freeze the 
    browser, uncomment the lines at the end of something.js.<br><br>If you play 
    around, you'll see that IE browsers accept (in something.js) an imported .js 
    file or a native function, but not both (without freezing).<br><br>This 
    behaviour has totally scuttled the site I'm working on...\r");
    Response.Write("</div>\r\r");
    Response.Write("<div style='float:left; width:680px;'>\r");
    Response.Write("<iframe name='somethingholder' id='somethingholder' 
    style='width:600px; height:350px; padding:40px;' src='dummy.htm' 
    allowtransparency='true'></iframe>\r\r");
    Response.Write("</div>\r\r");
    Response.Write("</div>\r\r");
    Response.Write("</body>\r");
    Response.Write("</html>\r\r");
     
    Response.Write("<SCRIPT type='text/javascript'>\r");
    Response.Write("writesomething()\r");
    Response.Write("</SCRIPT>\r");
     
    %>
     
    //this is the function that writes to the iframe: call it "something.js".  
    Save it in the same folder as the rest.
     
    function writesomething () 
    {
    var odoc = frames['somethingholder'].document;
    odoc.write("<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01//EN' 
    'http://www.w3.org/TR/html4/strict.dtd'>\r");
    odoc.write("<html lang='en'>\r");
    odoc.write("<head>\r");
    odoc.write("<meta http-equiv='content-type' content='text/html; 
    charset=UTF-8' />\r");
    odoc.write("<meta name='description' content=' ' />\r");
    odoc.write("<meta name='keywords' content=' ' />\r");
    odoc.write("<meta name='Author' content='DA Ward - daward@worldnet.att.net' 
    />\r");
    odoc.write("<meta name='copyright' content='© 2009 DA Ward, Associates' 
    />\r");
    odoc.write("<title>IE 8 Flaw iframe written by Jscript</title>\r");
    odoc.write("<style type='text/css'>\r\r");
    odoc.write("h1 {color:red; font-size:30px;}\r\r");
    odoc.write("</style>\r\r");
    odoc.write("<body>\r");
     
    odoc.write("<h1>Something.js writes the content of this iFrame.  Examine 
    it's code.<br><br>Uncomment lines to freeze IE 8 and 7.<br><br>Works fine in 
    Firefox, Chrome, and Safari...</h1>\r");
     
    odoc.write("</body>\r</html>\r\r");
    odoc.write("<script src='importedsomething.js' 
    type='text/javascript'></script>\r\r");
     
    //odoc.write("<script type='text/javascript'>\r\r");
    //odoc.write("function inlinesomething () {var xxxmmm = 'foo'};\r\r");
    //odoc.write("</script>");
    odoc.close();
     
    // this is any old outside javascript file: call it "importedsomething.js" 
    and put it in the same folder as all the others.   It is the script 
    referenced in the iframe.
     
    function importedsomething () 
    {
    var somethingelse = "see, I told you...!"
    }
    
    //this is dummy.htm . It is the temporary content of the iFrame until 
    something.js refills it.
     
    <HTML><BODY STYLE='background-color:#FFEEFF;'>
    <CENTER>please wait a moment....</CENTER>
    </BODY></HTML>
    
    
    
    Saturday, August 22, 2009 4:04 PM

All replies

  • don't know if this is a similar script...i suspect they do something with document writting here as well....BUT(and i really don't know where to post this bug since it's problematic on multiple machines using ie8)...
    http://www.izklop.com/link_enc.php?id=60758
    this link(after it redirects you to this specific page(zurnal24.si) freezes internet explorer EVERY TIME(with or without addons).
    And i've encountered other pages but the problem is always the same...usually an iframe redirect of some sort and poof CPU goes up and the browser freezes.
    It's quite annoying since this crashes all other iexplorer windows once you decide do close the process.

    Where the ____ can somebody post such bugs and why are they not getting fixed(i've seen several posts on msdn and other pages in the past year and still nothing is getting fixed).
    If they want us to continue to use this browser they should be fixing bugs not just working on making the next version(every 2-4 years) better than the last but with horrible bugs that never get resolved.
    Friday, March 12, 2010 3:10 PM
  • Hi DA,

    We are volunteers here. Could you please post a link to your online version of the page. Our development and testing environments may not be the same as yours. It wastes our free time to create a sandbox for your test case. I have not had VS6 installed for nearly 8 years now.

    My Guess though is

    use \n instead of \r or just omit the linefeeds or newlines entirely.... browsers just use them to make the markup source more readable.
    IE may be having problems with the unicode conversion of \r since the markup is injected on the fly.

    If I had a link to your page I would start by loading the page in FireFox and then using the Tidy HTML extension to validate the computed markup as the IE8 Developer tool cannot parse the DOM from an injected markup. It is important that when using the Tidy validator that you correct all Warnings as well as Errors. What are warnings in FX may be errors in IE browsers. This is a security measure... Junk can sometimes be malicious.

    Here is a link to the MSDN documentation about what is new to IE8.

    http://msdn.microsoft.com/en-us/library/cc288472(VS.85).aspx

    You will find some important and relavent information there about scripting across iframes.

    Regards.
    Rob^_^
    Friday, March 12, 2010 10:41 PM
  • Hi Loopy,

    If I add your site to the Restricted sites zone it will load indicating that indeed it is your injection scripts. The same answer applies to you also as there are numerous warnings from the Tidy HTML validator.

    One glaring problem is your use of a strict DTD. But there are over 30 warnings in two pages in the frameset.

    Although I think that the FB api's and XSS issues are comming into play also.

    Have you considered that the FB api's may be faulty or that they are serving up different versions for different browsers. IE6 and earlier browsers do not have native XMLHTTP support... is one. Run the FB homepage through a validator... I really do not have confidence in the quality of their developers code.

    It may be that you are trying to do something with the FB api's that IE8 considers a security risk and is rejecting some of the <script> blocks. Other less secure browsers may be allowing them through.

    The issue reporting portal for IE8 at connect.microsoft.com is no longer taking new feature or issue tickets... Its been over two years now that web sites have had to prepare for IE8. Sorry you are too late.

    In the first instance correcting the Tidy HTML warnings is the place to start, but also taking into considerations of XSS and cross frame scripting that is outlined in the MSDN article that I quoted to DA.

    http://msdn.microsoft.com/en-us/library/cc288472(VS.85).aspx

    Hopefully becoming more knowledgable about the workings of IE8 will give you an appreciation of its supperior security... I am not a MS employee... I reguarly use all the other browsers and have developed with asp and jsp. MS products are simply far superior to the other IDE's.... There are 60 day trials available of Expression Web from technet or msdn.

    Regards.

    Rob^_^
    Friday, March 12, 2010 11:27 PM
  • Look guys.  I've changed doctypes.  I'm using IE 9.  This behaviour hasn't changed.  If the browser is reacting to cross-site scripting issues, it ought to be well enough behaved to give me an alert box, telling me. 

    Freezing solid, developer tools and all, is just so...amateur.

    I've put the dang thing on a text server so you can try it yourself.   Check the explanations there, and the source.

    First, the commented out (working) version: http://69.63.82.164/IEflawDemo/something.asp

    Now: the freezing version: http://69.63.82.164/IEflawDemo/somebadthing.asp

    Of course, you'll have to look at the latter in a firefox-like browser....

    DA Ward

    Friday, September 23, 2011 9:39 PM
  • Now: the freezing version: http://69.63.82.164/IEflawDemo/somebadthing.asp


    Fiddler2 Hex view is showing that there is no line end on this

    http://69.63.82.164/IEflawDemo/inlinesomething.js

    Does giving it a line end help?   Oh.  Looks like you had that before and were told to take it off?   ; }

    Also, I'm wondering if that space between the function name and its parentheses could be causing a problem for a parser?  FWIW I think it looks odd.

     

    HTH

    Robert Aldwinckle
    ---

    Saturday, September 24, 2011 3:05 PM
  • Made the two changes you suggest to inlinesomething.js.  Still freezing IE.

    This is a really, really simple example of something that should be like "reciting the ABC's" for any browser.  The website I'm still working on has lots of javascripts both inine and exterior to the iFrame. 

    The combination does amazing things; the client has hundreds and hundreds of possible choices, and pow! the iFrame shows it.

    IE is still the major browser on the world scene.  The fact that it freezes, because of such an easy-to-demonstrate flaw involving very basic javascript constuctions, infuriates me.

    DA Ward

    Thursday, September 29, 2011 5:15 AM
  • This is old I know but I wonder if you ever found a solution to this problem. I have IE8 locking up when using an Iframe to pass content back to the browser (Excel file) for a reporting type solution. Works in all but IE7 and IE8.

    IE locks up.

    Thanks

    Tuesday, February 21, 2012 6:14 PM
  • Well, I can't provide a solution, but I can liven up this thread, and report what I've found. 

    The website I talked about in the correspondence above is now being shopped around Silicon Valley.  It makes websites with a few button pushes.  The solution was for the user's IE browser to incorporate and call Chrome Frame upon arrival at any page that used an iFrame to show the website prototype.

    Of course, Google, as usual, just pulled the rug out from under this.  Chrome Frame is no longer supported. 

    Although I haven't tested it in IE 10 or IE 11, IE 9 still freezes every time.  Except that on one of my laptops running within Vista 32 bit which had never had Chrome Frame installed, after pushing the recover button after the usual freeze, I got a message from Microsoft, stating that it was uploading IExplorer r2 (this was just a few weeks ago, a long time after IE 9's release). 

    After that upload, IE 9 works, on that laptop.  The iFrame initially creates a pause, and then the page recovers, with a new little icon showing a broken item between the reload and stop page icons, and after that everything works just fine.

    So, hallelujah.  But then, on another almost identical laptop, with Chrome Frame uninstalled, and running a fully updated Vista 32 bit, I push the recover button and wait patiently, but have never got that response.  The pages just continue to freeze...

    If this wasn't such a necessary part of the success of my website engine, I would laugh.  But as it is, I'm still looking for help....

    DA Ward

    Monday, December 23, 2013 9:12 PM
  • A rampant example of a code abuse

    You need to learn the basics of web development before you actually try to code for it.

    For starters instance: where does the script tag belong on an HTML document?

     
    Thursday, December 26, 2013 5:33 AM