Bug 8684 – GOOGLE Calendar: Assign to innerHtml with html consisting of an iframe + div, div drawn twice.

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[David Phillip Oster]

executing javascript: editor.innerHTML = html;

where html is a <div> containing a <table> containing an <iframe>, the <div> following the table is drawn double, although the DOM is correct.

To reproduce: In shipping Safari, or top of tree webkit, go to http://google.com/calendar You'll get a "not supported alert", hit "Cancel" to dismiss the alert and continue.

Log in to Google Calendar with a valid username, password. 

In the main Calendar window,
At the top right of the window, are three links: Settings, Help, SignOut.

Click Settings.

You'll get 4 webform "tabs" General, Calendars, Notifications, "Import Calendar". Click on each. Note that the "back to Calendar" (OK) div is drawn twice only on the "Import Calendar" tab.

The javascript that implements switching tabs works by assigning to the innerHTML property of a div, id=coverinner.

Tabs 1 and 3="Import Calendars" have the same div as their last element.

Tab 3 has an IFrame in a Table as the last nodes before the bad div. Replacing the iFrame by a string causes the problem to vanish.

A reduced test case would really help here!

[ABob]

Created attachment 8181 [details]
screen shot of the double text and double button

See bug for comment

[Alexey Proskuryakov]

I have tried to reconstruct the problem from the description, but my tests worked correctly, e.g.:

<div id="editor">FAIL</div>
<script>
document.getElementById('editor').innerHTML = "<div><table><tr><td><iframe src='data:text/html,IFRAME'></iframe></td></tr></table><div>DIV</div></div>";
</script>

[ABob]

Steps
1. Login to Google Calendar
2. Select the Settings link in the top right side
3. Click on each of the links/tabs: General, Calendars, Notifications, and Import Calendars
4. View the links at the bottom or see the attached png file.
Result is two "back to Cal" links and two OK buttons

Regression:
This problem does not occur on FireFox
In Safari 2.0.3 Clicking on the back to link or Ok buttons yeilds a Undefined Value in the Java Console:
Undefined value
http://www.google.com/calendar/20060508132451doozercompiled.js

function Xn(a,b){if(!wd()){return false}var c=m("cover");var d=m("mainbody");if(a){if(G){G.hide()}if(Gc()){Tc("cover",vo)}else{Tc("cover",ae)}d.style.display="none";c.style.display="";document.body.scroll="auto";Ng(b);if(Mh){og=true;Mh=false}}else{c.style.display="none";d.style.display="";if(u&&!R.Qa()){var e=E(I);var f=e.f();e.date+=u.J-1;var g=e.f();R.da(f,g,false)}if(R)R.Eb(null,ak);document.body.scroll="no";if(og){og=false;rc(Ii())}}return true}

[David Phillip Oster]

Just copying the DOM of the offending page to a file, and loading the file does not reproduce the bug. So, the bug must happen because of how I am stuffing the IFrame. Now to track _that_ down.

[David Phillip Oster]

Nope: The only procedure I've got for this bug is exactly the one in the orginal description.

With the source, clicking the "Import Calendars" link causes a crash/assert:

#1	0x9012dff4 in abort
#2	0x947b20b0 in __eprintf
#3	0x01aba058 in WebCore::Node::createRendererIfNeeded at Node.cpp:878
#4	0x01ac1af0 in WebCore::Element::attach at Element.cpp:488
#5	0x018d9c38 in WebCore::ContainerNode::attach at ContainerNode.cpp:574
#6	0x01ac1afc in WebCore::Element::attach at Element.cpp:490
#7	0x018d9c38 in WebCore::ContainerNode::attach at ContainerNode.cpp:574

which is:
void Node::createRendererIfNeeded()
{
    if (!document()->shouldCreateRenderers())
        return;
    
    assert(!attached());  // <-- this is where it crashes.
}

Created attachment 8228 [details]
Reduced test case

In a debug build you get an assertion failure when you click Test. In a release build you get a duplicate "foo". The problem is a double-attach, with the first attach being called during load event dispatch for the iframe (which invokes Document::updateDocumentsRendering, leading to the attach).

[David Phillip Oster]

Thanks to [e-mail] I now have a workaround for this bug: instead of assigning the equivalent of 

foo.innerhtml = '<div><iframe id=a></iframe><div id=b></div></div>; 

I do:

foo.innerHTML = '<div><div id=a1></div><div id=b></div></div>;
diva1 = findbyid('a1');
diva1.innerHTML = '<iframe id=a></iframe>';

I wonder if something like this is the reason that image load events are delayed, and if so, whether such an approach could work here.

[Anders Carlsson]

I did some research and that is indeed why image load events are delayed.

Anders suggested that bug 6471 might be related.

[Anders Carlsson]

This was fixed in r15170