Bug 68661 - innerHTML call returns before DOM is rendered in element
Summary: innerHTML call returns before DOM is rendered in element
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-22 15:17 PDT by James Hartig
Modified: 2011-09-22 23:03 PDT (History)
2 users (show)

See Also:


Attachments
test case (doesn't reproduce) (2.36 KB, text/html)
2011-09-22 22:01 PDT, Alexey Proskuryakov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Hartig 2011-09-22 15:17:30 PDT
After the innerHTML setting returns and moves on to the next command in JS, the DOM hasn't finished parsing the new HTML and the next call fails because the element it is looking for doesn't exist. The HTML is in the element it just hasn't been parsed yet by the DOM.

Example code (actual htmlString: http://pastebin.com/JUHYy9Yt)
element[0].innerHTML = htmlString;
console.log(document.getElementById('services_content')); //returns null
console.log(element[0].innerHTML); //prints the html in console though

If I wrap the next call in setTimeout with a timeout of 0 then it works:

element[0].innerHTML = htmlString;
setTimeout(function(){console.log(document.getElementById('services_content'));}, 0); //returns actual element

The innerHTML is <1900 chars so it is by no means something huge. The call after setting the html loads content into one of the divs and thus fails because the element doesn't exist yet.
Comment 1 Alexey Proskuryakov 2011-09-22 22:01:29 PDT
Created attachment 108440 [details]
test case (doesn't reproduce)

I made a test from the bug description, and cannot reproduce this problem with Safari 5.1.

Could you please check what the difference with your code is, and/or attach your full test case?
Comment 2 James Hartig 2011-09-22 23:03:08 PDT
Unfortunately this appears to be something up the call stack. I can reproduce the issue a million times but only if the call stack originates from a Facebook JS SDK function.