From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25260 invoked from network); 16 Nov 2020 07:54:19 -0000 Received: from hurricane.the-brannons.com (2605:2700:0:17:a800:ff:fe3e:bc77) by inbox.vuxu.org with ESMTPUTF8; 16 Nov 2020 07:54:19 -0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by hurricane.the-brannons.com (Postfix) with ESMTP id E266021DE04 for ; Sun, 15 Nov 2020 23:54:13 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by hurricane.the-brannons.com (Postfix) with ESMTPS id AFDCD7788C for ; Sun, 15 Nov 2020 23:54:13 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id c17so17539128wrc.11 for ; Sun, 15 Nov 2020 23:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=CxhXLPUUzUH8J1q4NA/YFxXa4g30LU2K8Myk0Vy54ks=; b=G7UPAQ15UxtyqDkZryp2423ddgl4Jyo4mFBqEGpjD39Dqn2Q3R7khldjdb+O2rMj3i qtTqBMby1RentJlkEX5SuzJ/iMPzt2VbqYW301+aJBwOQBQ41+tStd5vvMkRVtVIaVtC 6/eqWQ0yty85Oyo6+HJIM40O7aoZmXcCll6Bj8QZoQ/uPXqZ6y2B/H/Mg0xw1XWuOC53 00fznwaU1JHOg53R0cz+Ber9Lj45Hy8QgnMIFGfMR+Gnxmw17eg3VR9iO9lXGTP2fAwx tlBTmLcs0+SLMi3qzfMhKMk8PRYA57hF8p36ma+sLNH1lnA9+XgODIAgNhMc513cY4FV tdBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=CxhXLPUUzUH8J1q4NA/YFxXa4g30LU2K8Myk0Vy54ks=; b=HwnX1pPZtUQhLfcNMLg6BjqaPNHdtNiChZtvqL7FRLSFq8pWI0iKGedwyclEZh0yew 9f1A7Wypc9y+AaNR76/QrfJac05eSjacLdtoSdDVEkwdwERANO8L+817v/KLRUsHBcZq gHuA3WquFoJDEuH3sGobuk/ZKr8AfgkIHSrLGNf0f8zgJ9XvqPAB3OIWYOrKbYL+3p7t EWZBzK+1H00DqxuKD5iasuGnCuPhNv82Lgj/L3AXaS3Z0gCEgJtmGo+39LU3mIIIhAwM zaUOzXciEHfCsWDG+o/8DrOdA/t4lngnQgKxGvz8PXjeszfA9o6Xly5zwQLGPK9AlvOp ESvQ== X-Gm-Message-State: AOAM532WfLDNGQwNDtKXd5Ko3lwmmXzYCO8Li9EiDgmqz9wATjW6t+/o JtFfeuAQNn39EagiYM47ijc= X-Google-Smtp-Source: ABdhPJzfZ+IGAi4vBTg3mbAmEDMTaUZ/simXDMvR93lU7Tq/uQB+t3woGYkzH7ctKojAjthcX9UDlA== X-Received: by 2002:a5d:66c3:: with SMTP id k3mr17478406wrw.123.1605513251972; Sun, 15 Nov 2020 23:54:11 -0800 (PST) Received: from toaster (b.5.b.9.4.f.e.f.f.f.c.f.1.b.a.e.1.4.0.9.2.4.1.1.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:1142:9041:eab1:fcff:fef4:9b5b]) by smtp.gmail.com with ESMTPSA id n10sm21220054wrv.77.2020.11.15.23.54.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Nov 2020 23:54:10 -0800 (PST) Date: Mon, 16 Nov 2020 07:54:09 +0000 From: Adam Thompson To: Kevin Carhart Cc: Karl Dahlke , edbrowse-dev@edbrowse.org Subject: Re: [edbrowse-dev] interwindow bleed Message-ID: <20201116075409.GA2434468@toaster> References: <20201005232257.eklhad@comcast.net> <20201109231116.GB4369@toaster> <20201009202834.eklhad@comcast.net> <20201115122657.GA10863@toaster> X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Nov 15, 2020 at 07:27:31PM -0800, Kevin Carhart wrote: > Hi Adam > > > As a question, what is the promise stuff they're lacking? It looked like > > they implemented this but I really don't know js enough to have an opinion. > > It could be any and every ES6 feature. Adoption is increasing as time goes by. In July I worked on nasa.gov and got it working again. Between July and now, they wrote in all kinds of ES6. One example is a new use for the backtick symbol in place of quotation marks. It's used in JS somewhat analogous to the use of backticks in bash etc. So now nasa is broken again because of something you can't write a JS shim for. (I've heard of transpiling to ES5, but I don't know how to do it or whether it's something we could do on the fly.) > > Various sites are using 'let' a lot more. That's unfortunate. They claim some level of compliance with es6 and 7 but I guess that they're not keeping up with the newer standards. the latest I could find was a standard from 2020 but the duktape feature comparison only references up to about 2016 (and only with partial support apparently). Given there're still active commits I wonder if there are plans to catch up but I guess we may not have that time. > We were working with dominos.com and they need postMessage. We wrote a JS implementation of that one. Interestingly, when I looked (briefly) at the latest es standard this was only referenced as an example synchronisation mechanism, with the implication that it'd be implemented as part of the browser rather than as part of the js standard. However, with some of this stuff that distinction appears to be becoming rather... questionable. > There's also the function bodies. This one isn't ES6-related. moz and v8 allow toString() of a function and return the source JS. We think this is needed if we were to get ambitious and support paypal.com. We spent a few weeks on it and solved several things but then ran into the buzzsaw of an obfuscated file they use which even has "traps". And function bodies is part of what it's trying to detect. That's too bad about the tostring. It looks like there was a thought about implementing this but I guess it never got fully implemented. I remember there was much discussion about what duktape does now in the case someone runs this and I read some indications that they thought to implement a function.source property to allow this. However I've no idea if this was ever done or if one needs custom config at build time (I could go further into the code to find this but the yaml based config system which they use I find... confusing). > It's too bad. duktape is terrific. They don't not have the features, > they're just someplace in the middle. I think probably due to the massive amount of work it takes to incorporate them. also because some of the features probably sit in that unfortunate place between browsers and js engines. When one develops both this is less important because one can "make things work" but when one is using a js engine which one doesn't develop this becomes somewhat more important. I guess what I'm concerned about is the same concerns which motivated me to suggest duktape all those years ago. For example, Debian already packages mozjs 52 and mosjs 78. Apparently we (in our hello program), thanks to Karl's dedication now have support for 52 and 60... I'm hoping there's a comparison between 60 and 78 in terms of API or how we keep up with this. I'd rather we not be the reason that distros have to keep old versions of mozjs around again. However if that's what we have to do to keep a useful browser then I'll do what I can to help. Cheers, Adam.