From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 7DDE177C94 for ; Sun, 23 Jul 2017 17:52:26 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id ZRbad0faIOZSqZRbydVgMs; Mon, 24 Jul 2017 00:52:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1500857558; bh=tnDJyY0fwF3/vMKkazFdoINCyx1IL7BkqGefhmlk57A=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=Zzs3N1x88SJHbKzJTyW2wbHQE6+Wbd0LHNaOE1KfPlm2rKOHsWJhzBQCDZs+Edv40 9Ffo4gpf3wFfDckz/8uWR5QaDv1phWgrAyw08d2Beihr7KfFk90W/zKbeX3FTz3/q6 6KaJVkw9JWf1E0V5uwDW+1QqUK8nXsvDqIaazwr/u/Oay+lqGvtV1iL/BaNpf0B/v3 2s7mRQhrCX1IyMLYPJ4CCGnQNn2Rew1tC+UmIJjXbEhQq2bdxU4H13/x90DER7alXr c1PC87lv5U/LU9fyf8P+gbnHn9IaKP70f8ueo/6l1MhYCpP1iIqRcWeexDK7cUq8gK yalFvk0w1HKWg== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-16v.sys.comcast.net with SMTP id ZRbydBDu8RWTeZRbyd6fwV; Mon, 24 Jul 2017 00:52:38 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.7.0x Date: Sun, 23 Jul 2017 20:52:38 -0400 Message-ID: <20170623205238.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-729100 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfPWN2tdpttl2KYMpfeempQrrJO66bPBw3bvhiLRIBUfH15yPD5spATIdjCqz6tSzgriBYrBaJXQLfzM47S8OXHMNeM/7rRXhC9HOcoomOUuoB+diAOYu jQxMWMcHDi6lOxGwyU4ap7NQ9z/h//3kl86tGlqBj6WrhcutFNto4QvI Subject: [Edbrowse-dev] Object identifiers X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 00:52:26 -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-729100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable As you know, we use the pointer to the object as the link between that = object in the js world and the corresponding html tag in the edbrowse = world. We did this in Mozilla, and naturally carried it across to duktape. The documentation guarantees these pointers are valid, as long as the = object is not garbage collected away. We've come to learn that's a mighty big if. I wrote a fair amount of code to make sure we weren't diddling with an = object that was thrown away, because you get a seg fault if you do. = Boom! But then there's a bigger problem. I'm sure this was present in mozilla, but we never got far enough down = the road to see it. tag1 links to object1 by pointer1, and javascript removes object1, and = it is thrown away, and creates object2, which happens to use the same = pointer1. It passes pointer1 back to edbrowse, which already has this recorded in = tag1. So now tag1 is linked to object2, which may be a form instead of a div, = may have different number of children, etc etc. It is potentially bad, with unpredictable behavior, and nearly = impossible to reproduce. We went down the pointer path because neither engine gives you an = unambiguous handle to the object. So now I'm writing more code to know that object2 is new, and even if = it uses pointer1, which we have in our registry, we should delete that = tag and make a new one, and I already broke edbrowse in a mysterious way, and it's just = badbadbad. So I'm thinking instead, why don't we create our own IDs. Just a sequence number that we put on every object we care about, and = an array to map back from sequence number to the object. A bit of overhead, but no crashes if we accidentally reference an = object that is gone, and no ambiguity - one object per id. Change jsobjtype from voidd * to int, and systemically change = everything else accordingly. A fair chunk of work, but might be worth it. I really don't have a better alternative right now. What do you think? Karl Dahlke --nextpart-eb-729100--