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=2.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FROM,HDRS_MISSP autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 24531 invoked from network); 7 Mar 2021 13:26:45 -0000 Received: from hurricane.the-brannons.com (2602:ff06:725:1:20::25) by inbox.vuxu.org with ESMTPUTF8; 7 Mar 2021 13:26:45 -0000 Received: from localhost.localdomain (localhost [127.0.0.1]) by hurricane.the-brannons.com (OpenSMTPD) with ESMTP id 9cd62804 for ; Sun, 7 Mar 2021 05:26:39 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [2001:558:fe21:29:69:252:207:35]) by hurricane.the-brannons.com (OpenSMTPD) with ESMTPS id 46288b3d (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO) for ; Sun, 7 Mar 2021 05:26:14 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id It83lixvFzQhpItQCldpWm; Sun, 07 Mar 2021 13:26:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1615123572; bh=V3WDcyvoqKmH6LAJV5ilOOnzQ7YiAbuQkONH4d3oQ9E=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=FqqswUw/YNYM0MD+nW2vA4UsPDx00qSX+mDUsG44CGRl64npSNFHfTaunCh6cs5Tt zWN2BiZNmvKPo+EmO2mptubaFff1jYJ/93fYpH2lLogPcSj176GMAY8crIhNGJsIqm QmHQauAkUNihpIw+pPdgROEynlU42GYWZF5Kc0Sgpaezlgnb5TvJBASQlhE8vu85Ox f4zxfPevPM9JgBTRIH8ZJLsgnzzit987d3+JZmJu0nAKLmcwjxHrsuz16TaUuz/WR5 D3Wl+1t9NmcQ18sVlwYMfpwEMj7FZ1UBuoIa5wpUiIc1833L010WD6Mj1BrD6YlyZK EUleReECqi68g== Received: from unknown ([IPv6:2601:408:c300:a3d0::8f8f]) by resomta-ch2-17v.sys.comcast.net with ESMTPSA id ItQAlbI9Vr8DXItQBlIX60; Sun, 07 Mar 2021 13:26:11 +0000 X-Xfinity-VMeta: sc=0.00;st=legit To:edbrowse-dev@edbrowse.org From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.7.7 Subject: [edbrowse-dev] quick js Date: Sun, 07 Mar 2021 08:26:10 -0500 Message-ID: <20210207082610.eklhad@comcast.net> X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-778785 Content-Transfer-Encoding: 7bit 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-778785 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Almost a year ago we realized,with much disappointment, that duktape = was far behind, and showed no sign of catching up. Meantime more and more sites were using features that duktape couldn't = even parse. As Adam said 7 years ago: if edbrowse isn't a fully functional browser = with js support, it will eventually die. So what to do? We looked briefly at v8, but there is no documentation on how to use = it, and it's c++, and very complicated. It's not that the documentation is bad, it doesn't exist! So I turned again to spider monkey, which we were using many years ago, = until duktape came along. Spider will always be up to date, as it is part of Firefox, so that's = good. I made a new effort to use it, and got further along than we did in = 2013, but I still can't figure out frames and cross compartment access, = which most sites employ. Here is a slightly helpful article. https://andreasgal.com/2010/10/13/compartments/ But that's not helpful enough. After several months I had to give up. Only a Mozilla insider could make this work! Then along comes quick js, which is up to date, for now, though it = isn't part of a commercial browser, so might fall behind, just like = duktape, and yes that makes me nervous. But it's there, and it's current, and it's almost as easy to use as = duktape. Not quite because of some tedious free malloc issues, which I won't get = into here, but it's close. And it's C, so no c++ libraries and interconnections with the rest of = edbrowse. The api is so intuitive you don't even need documentation; just read = the prototypes in the header files, and play, and experiment. What a refreshing change! So ... make edbrowseqk will build the quick js version, assuming you = have already cloned and built and installed quick js. git clone https://github.com/bellard/quickjs That's good, maybe we can go back to whatever we were working on a year = ago, after our long detoure. But there are questions. * I'd like to make quick part of the official edbrowse, as of version = 3.8.0. I know that's a big leap, but duktape doesn't work (on most sites), = spider doesn't work (on most sites), so it's hard to see why we shouldn't make the leap as soon as possible. Once edbrowseqk doesn't core dump, and yes I still have a few of those, = but once we're past that, seems like quick will do better than any alternative that we have right = now. Thoughts? * Then there is the makefile, and not sure why we have two, or if we = need two. Can't the makefile work for everybody, and forget GNUmakefile? In any case, if duktape is replaced with quick, the build procedure = changes, and the documentation in README must be brought up to date. * quick builds a static library, not a shared library - does this = present issues for our distributors? * Quick error handling is still open and not well understood. Check for exception, clear exception, capture exception and put it into = the debug stream. Right now I call a standard dump routine that prints the error message = to stdout, in not the best format, and if you use db>file to capture the debug log, that message won't be = there. So that's an open item. * Frames present every browser with a security risk, which we have = never addressed. duktape doesn't care, quick doesn't care, spider cares so much that I = can't even figure out how to do it! The problem is: a bad site, evil.com, could bring up an innocent = looking home page, then call up paypal in a frame. "Use paypal to pay for your sox." As you enter your password, or other juicy things, evil.com can see it, = because it's a frame. frame[0].contentDocument.forms[0].password.value Browsers have to prevent this, and we don't, and we never have. There's some kind of cross origin criteria that I don't know, and = haven't implemented. A frame has to have the same domain as the page above, or subdomain, or = I'm not sure. Any help appreciated. * Then there's a lot of find&fix to do before we cut a release. Mostly making sure it doesn't core dump, but besides that, there are = some missing classes and properties just cause quick is a bit different, or perhaps we never got it right in the first place. Remember we've spent almost a year not working on our dom at all. As you see, this was too long for the chatroom. But that's what this list is for. Reply with any thoughts. Karl Dahlke --nextpart-eb-778785--