From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 6565577DC4 for ; Sat, 28 Jan 2017 02:26:51 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-11v.sys.comcast.net with SMTP id XQEJctOkN6nWCXQEJcvR8I; Sat, 28 Jan 2017 10:27:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485599255; bh=BrcystYktemdyZEe1csoiidjFpr0bG9IXm+YCnzyaqQ=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=fGYVNo/uWoc1XvB/0RSJDpP+tcPPGPKpRM6FPdMY4N+RytBIwe4ymP4+dF2tGQnVH y44ybvitmPIIj+4jJ0YKPi7kShjjtCOVFGNZ85u3nVU4tX2OksLikui4oo7zwoMAjL Q/XX/xaPzhTl6HvdzoESf9ZlJRr7+Omki/7zP12JyXt2yyfctaaHoa54n38J3x5Sdk VZnh/CtyuKpKx56ToXqvESpdxzhAKTRvq5DgTn8bf08YA2mgVE1a5BINeOWiUodN+J 0SYGL/cJlR4fuJTDAQuvHu81P2AoNd93/xi+zdR/tnMejrXK5sjP3AMmyhs8W5hshu 62JVRaryUAImw== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-20v.sys.comcast.net with SMTP id XQEIcTuZcfscGXQEJcWnXV; Sat, 28 Jan 2017 10:27:35 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.6.2+ Date: Sat, 28 Jan 2017 05:27:34 -0500 Message-ID: <20170028052734.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-945953 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKP1D9iz+fRrqMXsK5ke9x885zkHCPz1RkzOJ5yWiEjXiWK9Dt6rZXJzp7a2mlcoI8HhYeIFRjTXAyFxiOqEQZ0DR//N0oZH4ZKnGbHwgBvhX90qemIy D1Bqb+N7VN8Vk9k5Yv+iVRIYqShPbARvY5yNfmDASbOQk0xamM8NiH7q Subject: [Edbrowse-dev] infinite loop js while() X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.23 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 10:26:51 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --nextpart-eb-945953 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable After some detective work, here is the js that causes the infinite loop. It creates two nodes, ft and fg, uses ft.innerHTML to put some nodes = beneath ft, then has a while loop that, I assume, moves the nodes from ft to fg. Here's the code, then more thoughts below. var = rid=3Doio.at_ei,fg=3Ddocument.createDocumentFragment(),ft=3Ddocument.cre= ateElement('div'); ft.innerHTML=3D'<'+'div class=3D"'+oio.at_ec+'" id=3D"'+rid+'" = style=3D"'+oio.at_es+'"> '+'<'+'/div'+'>'; while(ft.firstChild)fg.appendChild(ft.firstChild); document.body.insertBefore(fg,document.body.childNodes[0]); Ok, so the generated html looks like this.
 
Running through innerHTML, that creates a node under ft. All good so far. Then comes the while loop, and the only way this isn't an infinite loop = is if appendChild removes the node first from wherever it is, then = appends it. I've been talking about this on the edbrowse side, in our own tree of = nodes, but here it is on the js side, strictly within dom, and it's the = same issue. I think this is not just compelling evidence, but a smoking gun. Even if it doesn't say so in the spec, appendChild and insertBefore = should remove the child from wherever it is first, then put it beneath = the new node. Then the while loop above simply moves all the children from ft to fg. = Zip zap. I'm going to think about this for a bit, cause if I just start writing = code I'll screw it up, but I'm pretty sure I understand the problem now. I just need to fix it with a small amount of code, and not breaking = anything else. I imagine if I fix it on the js side, by issuing a remove when = necessary, before the append, then all those actions will carry over to = the edbrowse side in our sideEffects, and I won't have to change any = code over there, it will just all work. Karl Dahlke --nextpart-eb-945953--