edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] infinite loop js while()
Date: Sat, 28 Jan 2017 05:27:34 -0500	[thread overview]
Message-ID: <20170028052734.eklhad@comcast.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]

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=oio.at_ei,fg=document.createDocumentFragment(),ft=document.createElement('div');
ft.innerHTML='<'+'div class="'+oio.at_ec+'" id="'+rid+'" style="'+oio.at_es+'">&nbsp;'+'<'+'/div'+'>';
while(ft.firstChild)fg.appendChild(ft.firstChild);
document.body.insertBefore(fg,document.body.childNodes[0]);

Ok, so the generated html looks like this.

<div class="MBoxAdMain gp-ui" id="sponsoredwellcontainertop" style="position:absolute;display:block;">&nbsp;</div>

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

             reply	other threads:[~2017-01-28 10:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-28 10:27 Karl Dahlke [this message]
2017-01-28 17:02 ` Geoff McLane
2017-01-29  2:18 ` Kevin Carhart
2017-01-29  3:34   ` Karl Dahlke
2017-01-29  4:43     ` Kevin Carhart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170028052734.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).