From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kevin@carhart.net>
Received-SPF: None (mailfrom) identity=mailfrom; client-ip=8.23.224.60;
 helo=out.smtp-auth.no-ip.com; envelope-from=kevin@carhart.net;
 receiver=<UNKNOWN> 
Received: from out.smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.23.224.60])
 by hurricane.the-brannons.com (Postfix) with ESMTPS id 10E0F77893
 for <Edbrowse-dev@lists.the-brannons.com>;
 Thu, 22 Feb 2018 21:46:16 -0800 (PST)
X-No-IP: carhart.net@noip-smtp
X-Report-Spam-To: abuse@no-ip.com
Received: from carhart.net (unknown [99.52.200.227])
 (Authenticated sender: carhart.net@noip-smtp)
 by smtp-auth.no-ip.com (Postfix) with ESMTPA id 955232B1
 for <Edbrowse-dev@lists.the-brannons.com>;
 Thu, 22 Feb 2018 21:47:21 -0800 (PST)
Received: from carhart.net (localhost [127.0.0.1])
 by carhart.net (8.13.8/8.13.8) with ESMTP id w1N5lKwU006184
 for <Edbrowse-dev@lists.the-brannons.com>; Thu, 22 Feb 2018 21:47:20 -0800
Received: from localhost (kevin@localhost)
 by carhart.net (8.13.8/8.13.8/Submit) with ESMTP id w1N5lJYm006177
 for <Edbrowse-dev@lists.the-brannons.com>; Thu, 22 Feb 2018 21:47:20 -0800
Date: Thu, 22 Feb 2018 21:47:19 -0800 (PST)
From: Kevin Carhart <kevin@carhart.net>
To: Edbrowse-dev@lists.the-brannons.com
In-Reply-To: <20180122135418.eklhad@comcast.net>
Message-ID: <alpine.LRH.2.03.1802222137570.15866@carhart.net>
References: <20180122135418.eklhad@comcast.net>
User-Agent: Alpine 2.03 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: [Edbrowse-dev] return value from removeChild
X-BeenThere: edbrowse-dev@lists.the-brannons.com
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Edbrowse Development List <edbrowse-dev.lists.the-brannons.com>
List-Unsubscribe: <http://lists.the-brannons.com/mailman/options/edbrowse-dev>, 
 <mailto:edbrowse-dev-request@lists.the-brannons.com?subject=unsubscribe>
List-Archive: <http://lists.the-brannons.com/mailman/private/edbrowse-dev/>
List-Post: <mailto:edbrowse-dev@lists.the-brannons.com>
List-Help: <mailto:edbrowse-dev-request@lists.the-brannons.com?subject=help>
List-Subscribe: <http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev>, 
 <mailto:edbrowse-dev-request@lists.the-brannons.com?subject=subscribe>
X-List-Received-Date: Fri, 23 Feb 2018 05:46:17 -0000



I found some evidence that our removeChild function should return the 
removed node to javascript, instead of returning undefined

A prominent library file includes this line:

a.removeChild(b).style.display = 'none';

So it's expecting something to be there.

And MDN talks about removeChild being called in two possible ways, one of 
which returns the removed node:

var oldChild = node.removeChild(child);

"The removed child node still exists in memory, but is no longer part of 
the DOM.  With the first syntax-form shown, you may reuse the removed node 
later in your code, via the oldChild object reference."

Could this be done by renaming removeChild to eb$rmcd in jseng-duk.c, and 
then in startwindow maybe this?

mw0.removeChild = function(c) {
this.eb$rmcd(c);
return c;
}

The side effects are all nice and stable already, so leave them alone and 
just deal with the change in what is returned to JS using a JS wrapper.
If this sounds OK, I'll turn this in.

thanks
Kevin