Cannot load pages from web server in IE 8. Get KB927917


  • I am having a subtle problem with IE 8.  We have a site with a number of pages that involve Google maps.    The site works if you use IE 7 or Firefox.  If you use IE 8, you will sometimes get error KB927917 regardless of the setting of the compatibility mode and other modes.

    I have done a more thorough investigation of this problem.  If I go into the IE 8 Developers Tools and set the cache mode to "Always Refresh from Server"  The pages all load perfectly from the source server.  They all pass w3c validation as well.    If I navigate around the site and then use the forward and back buttons, IE 8 refreshes the pages from the server as you would expect.  The whole site works flawlesly.  If I now disable "Always Refresh from Server" I can still use the forward and back buttons to view previously visited pages and the browser will render them from the cache without any problem and without contacting the source server.     IE 8 fails with the KB927917 error if I now navigate to a page containing a map and IE 8 contacts the source server to refresh the page!    I orginally thought this was a problem loading pages from the cache, but what I have observed is that it is a problem loading pages from the server (perhaps with parts being retrieved from the caceh.)  This is totally conterintuitive.  

    What is totally frustrating is that KB927917 claims the pages are  modifying a parent container before a child element is closed.   If that is the case, why on earth doesn't it include the ids of the elements in question and why if that is the case do the pages load flawlessly when "Always Refresh from Server" is enabled? 
    Thursday, December 31, 2009 7:53 PM

All replies

  • Hi,

    Check your settings for

    Tools>Internet Options, Advanced tab, Security section, "Enable DOM Storage" (default is enabled).

    You should always test your site with the default Advanced tab, and security zone settings.

    When you browse your site from the Visual Studio environment you are using the User's IE's settings.

    Google Maps uses AJAX and DOM storage to maintain state information about the zoom level and selected Pin positions.

    Sunday, January 03, 2010 2:05 AM
  • Rob -

    I run vanilla IE 8, so "Enable DOM Storage" is checked.   

    Perhaps you missed this key point:   All these pages load flawlessly if the IE8 caching discipline is set to "Always Refresh from Server".  This is true regardless of any setting like Security,  Browser Mode, Document Mode, etc. settings,   I hvae tried all of these at one time another.  One way of interpreting this is that nothing is wrong with the pages.   There are no parsing errors in FF or in IE8 when "Always Refresh from Server" is set.   It is when you turn this off and the browser attempts to load the page form the server that things go wrong.   There is some state / history saved by IE8 that causes things to go awry, but how do you find it?     The problem is the dignostic  "KB927917: HTML Parsing Error: Unable to modify the parent container element before the child is closed  at Line 0, Code 0, Char 0" is next to useless.   It is probably wrong (1) becasue all modification of the one DOM element is doen in the <body> onload function which and (2)  becasue the IE 8 has made it quite far down the <head> (~8KB when it quits) so it is well beyound Line 0, Code 0, Char 0)

    This almost surely an IE 8 bug.   What I need is a concrete, actionable, suggestion on how to make progress on debugging this.   The "try this, try that"  approach is akin to "shooting fish in a barrel".   I.e., it is unlikely to poroduce a solution.  

    Wednesday, January 06, 2010 12:56 AM
  • Ok.

    The penny has dropped. I just answerd your other thread and see that this is the same issue.

    Agreed, try this or that is futile guessing.

    Can we have the site link?

    (... some reflection.....)

    "KB927917: HTML Parsing Error: Unable to modify the parent container element before the child is closed  at Line 0, Code 0, Char 0"

    (... another penny dropped...)

    Here's the IE Blog post

    (I am sorry the KB927917 meant nothing to us in you first post. whent straight ahead and assumed standards compliance issues) Trying to resolve your issue over three threads is confusing.

    Nothing to do with a SQUID proxy then I guess.

    Wednesday, January 06, 2010 5:08 AM
  • Rob -

    OK.  Point well taken.  I will stick with this thread unless you indicate otherwise. 

    I have a test site that you can access.   It is password protected and I would prefer not to post the login credentials in the forum as what this site does is considered company confidential.  (However,  I do have permission to do just that.)   If you can suggest a way that I can pass you the information in a not so public way, I would prefer to do that.  (Skype might be one way, LinkedIn might be another)

    I have read that blog entry mmany time and also the related  MSDN Knowlege Base article.   I have pretty much convinced myself that the way the page is written,  it is not actually modifying an unclosed element.   After all the pages do load correctly if "Always Refresh from Server" is set.   This means they can be parsed and rendered without modifying an unclosed element.   Its more likely that it has something to do cached state information from  previously visited pages.  

    There are no Proxies (e.g. SQUID) but the pages are Java Server Pages  which adds to the fun.   The pages not containing maps are pretty vanilla JSPs and they are all fine (except that FireFox does point out some minor issues with some .css syntax).   The pages containing maps are also JSPs.  The non-map portion is vanilla, but the maps use a lot of JavaScript, but it is all straightforward function invocation (although the libraries provided by Google are probblay not.)

    I will take a look at the response headers as that is one area I have not looked at,

    Let me know how you want me to proceed on providing access to the test site.  As I said, I would be willing to do it publicly if you are not comfortable with any other approach.

    Wednesday, January 06, 2010 11:19 PM
  • Hi Andy,

    My email is valid. I use it as a honey pot for spam so unless your email has been hijacked by a spammer it should get through my filters. (I will not reply to unsolicited questions though, so if it is seen here by someone looking for answers, post your own questions here for everyone to benefit from).

    More pennies are starting to drop on my side.

    <quote>After all the pages do load correctly if "Always Refresh from Server" is set</quote>

    Ok... Fiddler will show you what is happening when you initialy request your page in IE8.
    (I am no expert about this. See Eric Lawerenc's Blog for some under the hood insights into IE).

    First it will download the html document and extract from it a list of the other resource that it needs (images, stylesheets and scripts) and send back requests for those resources from the server.

    As those resources are being pushed to the client, IE8 will start parsing the web document and try rendering the page as it moves through the DOM, creating nodes and appending children.

    The co-ordination between parsing and rendering the DOM and the recieving the resource files is called Marshalling. You can actually see IE8 do this on slow loading pages. The page renders from top to bottom in (I think) 50px blocks.

    During the initial load and parsing IE8 will hit the "Unable to modify the parent container element before the child is closed  " error and not execute the DOM manipulation script that is trying to append an element to an unclosed parent (probably the <body> since the script is called from the body onload event).

    Marshalling continues, and the rest of the document is rendered.

    When you use the IE8 Developer tool and set "Always refresh from server" only the requests for the resources are sent back to the server (again I think...). The completed DOM remains in memory and the resources are marshalled to it. So there is no problem. The <body> tag is already closed.

    Now, that should give you a big tip as to where to place your GMap function (I am working from memory here about your exact coding from your other threads), but I will wait until I have a look at your page before giving a definitive recommendation.

    <rant> Please ignore if you are not interested......

    Why was I so fixated about tweaking IE8's settings?

    Well it has to do with the way IE8 handles errors during the marshalling, completely different to other browsers.

    Tweaking IE's settings changes its error handling.

    Now... (this is my own thoughts)

    HTML and CSS are not programming languages. They are markup and layout notational instructions to a parsing engine like a browser. Your markup and layout is not compilied before it is pushed to a browser, so it could be full of errors or contain malicious instructions.

    You know that it takes some time for a C++ compiler to marshal everything and compile an error free machine code.

    So along comes IE8, aiming to be a more 'standards' compliant browser. This is a good thing for everyone, but IE has some legacy issues and it is also decided that it needs to be faster.

    Sweet. If it is built to accurately parse to standards then there is less of a need for error trapping and correction in the browser parser, they can make it faster... and make us code monkeys happy.

    Developers have been hounding MS to make IE more 'standards' compliant right?

    The problem is that those same Developers have'nt been coding to standards and they make mistakes in their markup and CSS is just about impossible for a lay developer to understand. (humans make mistakes, we need the validators to help us find and correct them before we publish it to our sites). Web design is a 'craft'.

    MS Visual Studio and Expression Web has Intellisense(tm) and error reporting that tells developers their mistakes and how to correct them before they publish their code to the web. If you like, a pre-compiler that ensures that the code is error free before being published.

    I have used Calypso for one client... I know how hard it is to write good validated markup in that IDE. PCVCS... ugh! Please shoot me!

    When testing your sites with FX you will probably be using the built in validator and although there may be a few warnings (things like missing closing tags) the page looks fine in FX.

    You open the same page in IE and it looks like Acid Test 2. WTF!

    You open the Devloper Tool and pess the Validation menu and the w3c validators returns errors, not warnings.

    You correct those errors and review your page in IE. This time it looks (generally) the same as in FX.

    You see where I am coming from (I am starting to rant... I will close soon)

    IE is actually more standards compliant, it is just that it is less junk tollerant than FX.

    For IE, junk in junk out is the letter of the law.

    From a computing science point of view it is more efficient to use pre-compilied or error corrected markup rather than have the billion or so client browsers handle the error detection and correction.

    There is no getting away from the Business argument that the majority of your site visitors will be using an IE browser. You should be targeting the browser platform of the majority of your visitors.

    Anyway send me your link and lets get your question answered. Hope my rant was helpful too.

    (we (volunteers) get our butt full of critics complaining about IE not being 'standards' compliant. I am probably using you to argue my case. Validate, validate, validate)

    • Edited by IECustomizer Thursday, January 07, 2010 6:48 AM Changed censored word to Acid test 2
    Thursday, January 07, 2010 6:43 AM
  • Rob -

    Interstingly enough, I am now beginning to get "IE cannot display this web page" errors when I hit reply to this thread, but that is another story.    I lloked at Fiddler last night and I think there is a chance is might provide some insight, but truthfully my expectations are a bit low.    I have already tarcked the TCP/IP traffic between the browser and server and have yet detected anything unusual.   Setting "Always Refresh from Server"  seems to make IE refresh every resource, but tracking that is a bit tedious so I am not 100% sure.

    Anyway, the pages in question pass w3c validation, although as you will see they are XHTML 1.0 Transitional.  I have tried other doc types but it does not seem to make difference.  

    I understand your points completely. 

    I will follow up with instructions on how to naviagte the site in your e-mail account.

    Cheers, Andy 
    Thursday, January 07, 2010 5:32 PM
  • Hi,

    You would have received my reply email confirming that I have your link instructions. I imagine that like you, it will take me some time to go through it.

    The refresh from server of the html resources, was something I was unsure about although it would explain why that works. Perhaps the resources are re-requested, timestamps are compared and if no changes it is not parsed again.

    The link to your production testbed will make it easier to solve than relying on this verbal exchange.


    Actually. I have some chors today. It may not be until Friday or Saturday your time that I will have a reply.

    Thursday, January 07, 2010 10:41 PM
  • Rob -

    This issue is not going to roll over so easily!   I did load Fiddler.   It is a great tool.  Thank you for the tip on this one.   

    Interestingly enough, when Fiddler is running, you seem to be able to navigate the web site without a problem.   As soon as you close Fiddler,  the problem occurs almost instantly the first time you visit vehcileLocationHistory for any driver/vehicle.  

    However, I did learn something.    If you have previously visited vehicleLocationHistory.jsf and you visit it again, perhaps with a different parameters, IE doesn't fetch much to render the page.    After it fetches the page, the only other resources it fetches are the map images centered at the new latitude and longitude.     When "Always Refresh from Cache" is set, the browser fetches many, but not all,  resources required to render the page.    Some items are obviously fetched from cache.    In both cases,  the map information is fetched in the the onload function load_gmap().    This function should not be exceuted until the closing </body> is encountered.   

    At the moment, I do not  have a plausible explanation or conjecture at to why loading fewer resources might  make a difference.    Obviously, multiple threads are being used to fetch the required resources and render the <body>   If load_gamp() is being executed before the <body> element is actually closed by the thread building the DOM object,  one can imagine all sorts of scenarios where the latencies involved in loading various map resources might allows the <body> element to be closed before the map starts being rendered in the <div id="map_canvass" ...> element and in other case where the <body> element is not closed before the map starts rendering in the <div> slement.     This would be a very basic error,  but workarounds posted by others having similar problems,  suggest that perhaps something like this is happening.

    Friday, January 08, 2010 10:22 PM
  • Hi,

    Sat arvo here. Just read your updated email. It will be Monday YT before I will have an answer.

    Fiddler uses a Proxy for its connection. The plot thickens..... I haven't loaded your site yet.... Its been too hot here to work... maybe tonight...

    Don't forget that GMaps is sourced from a different server than your own, so I am thinking that IE's Security Zones may be a factor. Cross site scripting/navigation across different security zones. (light bulb!) your sub domain structure.

    If you want to give it a go on your weekend. Try setting your IE security zones to their factory defaults.
    Tools>Internet Options - Security tab, click the "Reset all zones to their default" (if it is enabled) and adding your root domain to the Trusted Sites Zone. (You may have to recommend this to your clients using IE with some sort of message on your page.)

    Anyway I am pretty well kitted up here so I should be able to crack it. Just too hot, hot, hot...


    XXXXX Forget/ignore this post XXXXXXXXX
    • Edited by IECustomizer Saturday, January 09, 2010 11:22 PM
    Saturday, January 09, 2010 7:29 AM
  • Andy,

    I am posting here for everyone to benefit from.

    I am sorry (you have said that your pages had validated, probably in the FX Tidy validator, but they do not pass the w3c validators).
    You have not validated and corrected your markup. There are parsing errors on the pages.

    Here is my testing plan.

    Open FX and navigate to and login to your site.

    Navigate to one of your currentvehiclelocations.jsf pages (since you are using an Active Server Page language (jsp) your pages are dynamically built on the server, you should test all possible output scenarios from this server page).

    Press the Tidy Validator icon in the FX status bar (or from the Tools menu) to display the Tidy Validators' error report and CORRECTED output.

    Here is the Tidy Validators error report.

    line 47 column 1 - Warning: discarding unexpected <head>
    line 207 column 51 - Warning: '<' + '/' + letter not allowed here
    line 214 column 50 - Warning: '<' + '/' + letter not allowed here
    line 280 column 55 - Warning: '<' + '/' + letter not allowed here
    line 287 column 54 - Warning: '<' + '/' + letter not allowed here
    line 678 column 5 - Warning: missing <tr>
    line 682 column 5 - Warning: <br> element not empty or not closed
    line 682 column 9 - Warning: <br> element not empty or not closed
    line 685 column 28 - Warning: missing </span> before <table>
    line 777 column 204 - Warning: <nobr> is not approved by W3C
    line 779 column 19 - Warning: missing </span> before <table>
    line 780 column 1097 - Warning: <nobr> is not approved by W3C
    line 781 column 1089 - Warning: <nobr> is not approved by W3C
    line 782 column 1089 - Warning: <nobr> is not approved by W3C
    line 783 column 1089 - Warning: <nobr> is not approved by W3C
    line 784 column 1089 - Warning: <nobr> is not approved by W3C
    line 785 column 1089 - Warning: <nobr> is not approved by W3C
    line 786 column 921 - Warning: <nobr> is not approved by W3C
    line 786 column 1091 - Warning: discarding unexpected </span>
    line 786 column 1098 - Warning: discarding unexpected </span>
    line 16 column 1 - Warning: <html> proprietary attribute "xmlns:v"
    line 780 column 55 - Warning: <td> proprietary attribute "background"
    line 780 column 447 - Warning: <td> proprietary attribute "background"
    line 781 column 55 - Warning: <td> proprietary attribute "background"
    line 781 column 447 - Warning: <td> proprietary attribute "background"
    line 782 column 55 - Warning: <td> proprietary attribute "background"
    line 782 column 447 - Warning: <td> proprietary attribute "background"
    line 783 column 55 - Warning: <td> proprietary attribute "background"
    line 783 column 447 - Warning: <td> proprietary attribute "background"
    line 784 column 55 - Warning: <td> proprietary attribute "background"
    line 784 column 447 - Warning: <td> proprietary attribute "background"
    line 785 column 55 - Warning: <td> proprietary attribute "background"
    line 785 column 447 - Warning: <td> proprietary attribute "background"
    line 786 column 55 - Warning: <td> proprietary attribute "background"
    Info: Doctype given is "-//W3C//DTD XHTML 1.0 Transitional//EN"
    Info: Document content looks like HTML Proprietary

    Nothing but warnings, no fatal errors.... Ok you think? No.... look in the rhs pane summary. It clearly states
    "If you have only warnings, press the 'Clean up' button and Tidy will try to present a cleaned version of your page."

    Another hint that something is rotten in Denmark is the last 2 warnings.

    Info: Doctype given is "-//W3C//DTD XHTML 1.0 Transitional//EN"
    Info: Document content looks like HTML Proprietary (this indicates that the FX parser is not strictly redering your page to your DTD. In order to CORRECT your mistakes, it is making assumptions and either correcting or ignoring some of the errors. The corrected DOM, does not comply with your DTD, and so the warning.

    Close FX to end your session.

    Open your test site in IE8, Login and navigate to the same page.

    Ignore the "KB927917: HTML Parsing Error: Unable to modify the parent container element before the child is closed  at Line 0, Code 0, Char 0"
    error and press Ok and continue to load the page.

    (Now normally here you would press F12 to display the IE8 Developer tool, then the Validate>HTML menu to validate your page at the w3 validator, but becuase you are behind a corporate firewall and Tomcat which may be blocking the w3 spiders userAgent, you may get the error "Unable to validate this page")


    From IE select the View>Source menu and from the View source dialog, the Edit>Select All, then the Edit>Copy menu to copy your jsp output.

    Open a new tab in IE8 and navigate to and then select the Direct Input tab.

    Copy and Paste your source into the TextArea field. Press the 'Validate' button.

    Here is the summary

    Errors found while checking this document as XHTML 1.0 Transitional!

    <form id="form" action="check" enctype="multipart/form-data" method="post">
    Result: 60 Errors, 3 warning(s) <!-- this case where validation fails but no error is listed should never happen -->

    the very first warning is

    Mismatch between Public and System identifiers in the DOCTYPE declaration

    This document uses an inconsistent DOCTYPE declaration. The Public Identifier -//W3C//DTD XHTML 1.0 Transitional//EN declares the XHTML 1.0 Transitional document type, but the associated System Identifier does not match this document type.

    The recommended System Identifier for XHTML 1.0 Transitional is

    The safest way to use a correct DOCTYPE declaration is to copy and paste one from the recommended list and avoid editing that part of your markup by hand.

    But the showstopper that is causing the KB927917 error is

    Line 858, Column 7: "head" not finished but containing element ended 
     Line 858, Column 7: end tag for "head" omitted, but OMITTAG NO was specified 
    You may have neglected to close an element, or perhaps you meant to "self-close" an element, that is, ending it with "/>" instead of ">". 
     Line 19: start tag was here 
     <script language="JavaScript" type="text/javascript">  Line 858, Column 7: end tag for "html" which is not finished 
    Most likely, you nested tags and closed them in the wrong order. For example <p><em>...</p> is not acceptable, as <em> must be closed before <p>. Acceptable nesting is: <p><em>...</em></p> 
    Another possibility is that you used an element which requires a child element that you did not include. Hence the parent element is "not finished", not complete. For instance, in HTML the <head> element must contain a <title> child element, lists (ul, ol, dl) require list items (li, or dt, dd), and so on. 


    Ok. How do you fix it?

    Well, I don't have access to your jsp source.

    You will have to methodically work through the w3 validator report and correct the errors and warnings.

    Somewhere between your opening <html> and closing </html> tags you have an unclosed element.

    The snippet above gives you some hints where this is. (your script block before the <head> opening tag. All <head> blocks also require a no-blank <title> block also.) But you should aim to correct all errors and warnings from the w3 report. Your <script> blocks should be placed in the <head> block or within the <body> block.

    It takes a bit of practice to understand the w3 error reports, but with practice you will get the hang of it.

    As I said, since you are developing in an Active Server Page IDE (Calypso?) you will have to validate and test all possible output scenarios for that one jsp page -

    I would estimate that you are looking at one or two days work to correct everything, then another day to push it to your production environment and test.

    I cannot guarantee that correcting your markup will stop the KB927917 errors. I suspect that you will have to move the

    function from the body_onload event and place it in a script block after the </body> close tag.

    <script type="text/javascript>load_gmap();</script>

    or refer to the MSDN KB article.

    But before doing that you have to correct the markup errors. I know this is not your code and that you are inheriting legacy sloppiness. But you will have to fix your predecessors mistakes.

    You will benefit from the learning exersize.

    Good Luck!

    Saturday, January 09, 2010 11:07 PM
  • Hi,

    I just noticed that some 410 views have been made of this Thread.

    Hopefully the message will sink through to other visitors here.

    Validate, correct, test, validate,correct, test

    Not all validators are the same. You need to use a variety of tools to distill all issues and resolve them.


    Oh.... look at my previous post.

    The Telerik Textarea validator has place a </form> tag after my "Regards". I did not put that there. Pretty smart I think!

    See, with the right tools its a no-brainer. Humans make mistakes. Thats what all this smart software is for.
    Saturday, January 09, 2010 11:19 PM
  • Rob -

    I agree with your point about validate, correct, test ...   But I disagree with your analyis above.   

    First of all,  I did validate the pages through IE 8 Developer Tools without a problem.   I get excatly one warning which I know about.    W3C reports  "This document was successfully checked as XHTML 1.0 Transitional!"  Result  Passed, 1 warning(s).   The CSS valdiates as well.   For safe measure, I just performed the valdiation again.  I know about the warning which is "No Character encoding declared at document level"  

    Oddly, when I used the direct input method you suggested, I did get 3 errors and 3 warninngs for the same source!  but again nothing like the error above.   I will correct these erroes which are in fact probably not relevant.    The errors are on missing alt attributes on img elements. 

    I got nothing like the errors above are indicated.  So what tool did you use and why is it producing so many errors?   What page did you use the Tidy Validator on?   The clue that something is wrong is that if you scan all the html of the pages involved there is precisely one <head> and one </head>   I don't know how you could have an "unexpected <head>"  at line 47.  That is typically in the middle of the JavaScript function declartions afer you have passed the very first <head>.  Whatever tool that is, it is putting out bogus information.

    I rather wish you had not made the above  post until you and I were on the same page.  I think it may trun out to be misleading,   but what is done is done.

    Second,  I have run the whole site except for the database on a single machine outside of any coporate firewall.    That means the web server and IE 8 all runing on localhost.   I get the same behavior.   I have run IE 8 on fresh installs of XP Pofessional on single CPU machines.  Its been run on Vista and Windows , all  with the same result.   

    Now your suggestion that I move the invocation of load_gmap into JavaScript that is placed after the closing of the <body> element might in fact work.  Others have suggested it but I have not tried it.   But if it does, doesn't that suggest to you that the implmentation of the onload attribute of <body> in IE 8 is somehow flawed?   The script there is not supposed to be executed until after the <body> element is closed! 

    None of what you said above explains why if you set "Always Refresh form Server" or run though the  Fiddler proxy, the site works flawlessly.   The more I look into this, the more convinced I am that this is a subtle error in IE 8 which just happens to be revealed by the complexity of the Javascript in these page.
    Sunday, January 10, 2010 1:48 AM
  • Rob -

    And another thing.  The reason you get all these errors

       Line 858, Column 7: "head" not finished but containing element ended 
     Line 858, Column 7: end tag for "head" omitted, but OMITTAG NO was specified 
    You may have neglected to close an element, or perhaps you meant to "self-close" an element, that is, ending it with "/>" instead of ">". 
     Line 19: start tag was here 
     <script language="JavaScript" type="text/javascript">  Line 858, Column 7: end tag for "html" which is not finished 
    </html>✉ I
    ss becasue IE has not in fact loaded the  page completely.     The data in this site is static so the html served up is the same for every page you visit.   Validating pages on which IE 8 has choked is more than likley to yield errors.    The only way to properly validate these pages is to set "Always Refresh from Server" so the page in question loads properly, then validate.    If you had comapred the soures between a succesfully loaded page and one that was not successful, you would have seen that in the unsuccessful case the html was incomplete. 

    BTW, what version of IE 8 are you running?    
    Sunday, January 10, 2010 7:44 PM
  • No,

    My test plan does not involve the changing the "Refresh from server" setting of the Developer Tool.

    The IE View-Source is the actual output from you server (no scripts have been executed to add DOM elements)

    Use the Copy and Paste method to validate your page at

    You can use FX to copy your source if you like,


    Press the 'Tidy" button on the Tidy validator's report dialog and then compare the 'tidied' output with your source to find out where there are missing end tags. Or you may be able to translate your tidied output back to your jsp source.

    I am testing on Vista x86 SP2 with IE8.

    If you are using XP/IE8 you may be getting different results because you have a DTD that includes a link to the Microsoft VML namespaces.

    There is a bug in XP versions of IE 8. It is still honoring VML and MSO conditional comments which is causing headaches for web pages developed with MS Publisher. I did not see any usage of VML in your code, perhaps you can remove the link from your DTD whithout affect. (It may correct the incorrect DTD issue).

    Sunday, January 10, 2010 8:13 PM
  • Hi,

    If you are testing from localhost, the Developer tool validate and the w3 validate spiders wont be able to access the source html from your production server.

    You have to use your Production source to make the initial w3 validation.

    Then make your changes in your test environment (one by one) and validate by copy and paste into the w3 validator.

    I am not concerned about anything else ("Always Refresh from Server") until you have correct the markup parsing errors.

    Fix one thing at a time. The other issues may go away once you have corrected the validation issues.

    Sunday, January 10, 2010 8:27 PM
  • Rob -

    I am not currently testing on localhost, I am using the same sgspdev server that I pointed you at.   It is on the  same network as the production server and running the identical software (except for changes I just made) but a static and unchanging database.     As a consequence the same html is genreated every time you visit a page with the saem paramters.   Otherwise, this would be doubly hard to debug because you would be looking at different html all teh time.   

    I have no problem with w3c validation via IE 8 developer tools or with copy and paste to direct validation, although both methods suprisingly give slightly different results.   The errors are minor and not easily corrected as they are genreated by the particlular rendering engine (MyFaces) that we are using. 

    At the moment, I have installed a test build with the doctype issue fixed and a move of the invocation of the load_gmap to the place you suggested.   I still get the same error and further more w3c validation yields:  Line 1411, Column 33: document type does not allow element "script" here.   So actually for that doctype that  move was an incorrect thing to do.

    I am going to back out the move of the Javascript but leave in all the fixes to the markup that I can.   T

    As I indicated the site is static and the same html is created for each page every time you visit it.   So I respectfully suggest that you obtain the correct html for a page by setting "Always Refresh from Server"  and valdiate that first through w3c using both approaches.    I think you will be pleasantly suprised.   You will then get a better idea of why this is so frustrating.

    Sunday, January 10, 2010 9:21 PM
  • Hi,

    I just had a problem with the KB927917 error as well, and most of the usual streamed showed up with the same thing..
    Work around for IE 6, Work around for IE 7, doesn't happen in IE8, upgrade to IE 8, etc..

    I was looking through the whole thread and noticed Skype or LinkedIn as a communication vehicle between Andy and Rob.  I just disabled my Skype plugin/add-on and my KB927917 errors departed.

    Check and see what plugins you have that affect the DOM libraries.

    Hope this sheds some light on a solution for you guys.
    Thursday, January 21, 2010 9:09 PM
  • All -

    This thread has wandered into some pretty esoteric territory.  Let me sumamrize what I now know about this.

    1.  Since the beginning of this thread, I have verified that the production site works flawlessly in IE 7,  Firefox,  Chrome and Safari.
    2.  If you use the IE 8 Developer Tools to set "Always Refresh from Server", the site works flawlessly.
    3.  It fails with default IE 8 installations on XP Professional and XP Home Edition.    I have not personally verifed this, but users have reported the same failure running IE 8 on Vista and Windows 7.   I have verified that it fails on a clean install of XP Home Edition and IE 8, so it is not interference from plug-ins or other 3rd party SW, although that does not mean that these do not cause other problems.
    4.  The only pages that cause problems are those that involve Google Maps (which  use <body> onload and onunload attributes)
    5.  The reason that I asserted the pages passed W3C valdiation and Rob asserted that they do not is the result of what I consider an IE 8 bug.   All target pages in this site are the result of a redirection from a page that checks if you are logged in or not.    When you land at a target page, and use the Developer Tools to submit a target page for valdiation, it is this login page that gets validated, NOT the target page.   What is particularly misleading is that the URL W3C indicates as being validated is the URL of the target page.   Go figure!    I did not at first appreciate this difference.   Rob was correctly valdiating by cutting-and-pasting the source for the target page to the W3C valdiator.   I have since cleaned up many of the valdiation errors in a developemnt site, but this has not made one iota of difference.

    Frankly,  I am at a loss.   Given #1 and #2 above, I don't think this problem has anything to do with whether or not the pages strictly conform to a standard.    #2 indicates that IE can successfully parse the pages.    #1 indicates that whatver is unusual about this site is somthing many other popular browsers can handle.   What does it take to get Microsoft to look at this problem?

    Monday, January 25, 2010 8:14 PM
  • I can't get my developer tools to open in IE 8  any other ideas how to fix this???
    Thursday, August 12, 2010 5:10 PM
  • I thought I should close this thread. 

    Some time ago, this problem mysteriously disappeared.    I did notice that between the time it was failing regularly and when theproblme stopped happening, there were several updates to IE 8.   Mnay other sites I regualry visit had similar problems which have also gone away.    I would guess that MS finally fixed some problem in IE 8.


    Friday, August 13, 2010 4:12 AM
  • Hi I still see this issue and not able to fix it!


    Friday, August 13, 2010 5:48 PM
  • I have also researched this issue extensively and with thanks to IECUSTOMIZER for putting me on the right path, I think I may have figured this out. IECUSTOMIZER is correct that there are various versions of IE8 for Windows XP depending on when you upgraded to it. What worked for me was to upgrade to the latest version of IE8 which will involve the new installation forcing the current version you have to be uninstalled. Once uninstalled, the system wants a reboot before installing the newest version of IE8. Go ahead and allow the installation to reboot your system. Once your computer starts back up, it'll ask you to run or save the IE8 executable, go ahead and run it. Once it's done installing, download and install update KB2360131. Allow the reboot, and then try to access the page you were trying to when getting the error about KB927917. It worked for me and hopefully it'll work for you as well.

    • Proposed as answer by amapsr Friday, February 25, 2011 3:15 PM
    • Unproposed as answer by amapsr Friday, February 25, 2011 3:16 PM
    • Edited by amapsr Friday, February 25, 2011 3:17 PM Typo
    • Proposed as answer by amapsr Friday, February 25, 2011 3:17 PM
    Friday, February 25, 2011 3:14 PM
  • Thanks for your post I downloaded update KB2360131 and it fixed my error message- berto159
    • Edited by berto159 Tuesday, October 02, 2012 2:50 AM
    Tuesday, October 02, 2012 2:50 AM
  • For what it is worth.... I had some nested DIVs and they contained

    <div style="clear:both;" />

    which resulted in the error.

    Changing it back to:

    <div style="clear:both;"></div>

    fixed the error.

    • Edited by yaggier Monday, July 01, 2013 5:05 PM typo
    Monday, July 01, 2013 5:04 PM