From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 8D52277DC4 for ; Fri, 27 Jan 2017 02:08:56 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-06v.sys.comcast.net with SMTP id X3TRchfjQTERUX3TScWFjD; Fri, 27 Jan 2017 10:09:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485511782; bh=AvFinOvNXmcy+CH2dMf2nxP0i56g6phXNYahtjrznpw=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=bVzw9wLuT2sb6VU3nSPZ1kNG0FV8Y8Ejnm+urXSH5aBGMN2+6PDUTCuNFcGjzeUhA q3WsTv8esdYl9VhYTaHeKznueyHJNWna321L58xxoAjQEYA+DIeMj0973WAY5RbaHj ywZ+zfJP6S11zOOTqGnK0NpKvW1ZGbIlsvqq++nq4zdx9LaA97WRWe9KNhb6VUB+Xn O454NAY7xzbXkVa5RROkN2EJY9/T8QSbepg+bF+bmgR6PbPY2M5RcCLHgFbmglY+GQ WxEWvyVa/P+DIV7sNCXP+0cPry3vJ52XUkLH0ltBz+eszjmJN4iYcU3xhx+t6OA+Pf i6Qe9UpR839Cw== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-16v.sys.comcast.net with SMTP id X3TRcUEjiy3OZX3TRcq3nE; Fri, 27 Jan 2017 10:09:41 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke References: <20170026211901.eklhad@comcast.net> User-Agent: edbrowse/3.6.2+ Date: Fri, 27 Jan 2017 05:09:41 -0500 Message-ID: <20170027050941.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-215307 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNiMSG/8EnWcD8RfAE+zmeii0HzDRonj3K3v8Ou1XyDj8O5aU54HJ/jeDtKa8d1VIa0CdDTKX6CbLNMM0jxV5gVTvj5ZE3fEfMywap2yjf33UwE02Foc 3UYGDVEYslxEQ6J2WH1jz3qZQjxrhEO8IDNkY7pxJ6K4I2neBkxuPllH Subject: [Edbrowse-dev] Finding cycles in the tree 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: Fri, 27 Jan 2017 10:08:56 -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-215307 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > What do you think about trying to isolate the cause by going into the > version control and compiling edbrowse from different moments in = time, til > you hone in on the point of transition where Raw Story or Washington = Post > did work before a patch and no longer worked after it? I don't think it would tell us anything. This problem popped up because we got enough of the js working to move = forward, and make the links, whence one of those links does not make a = proper tree. Adam's removeAttribute for example, it works and the js moves forward. (Speaking of which, I made all the Attribute routines consistent, and = hopefully correct.) It's like turning on the light and seeing the mess. We wouldn't want to back up, we want to keep moving on. Delve into a site and find out why that link doesn't assemble a proper = tree - or check the spec again and maybe it says somewhere that I'm suppose to = unlink the node from where it was, if it was already in the tree, then = put it in the new place. db4 and watch all the nodes created from html, and dynamically, and how = they put together. Would be great if we had a site with no js errors, and still the tree = problem, then we'd know we were on to something. But these sites still have lots of js errors, lots of functions that = don't run to completion, so who knows. Maybe we could tell visually from another browser what the tree of = nodes is suppose to be. Karl Dahlke --nextpart-eb-215307--