From: Karl Dahlke <firstname.lastname@example.org> To: email@example.com Subject: [edbrowse-dev] quick js Date: Sun, 07 Mar 2021 08:26:10 -0500 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) [-- Attachment #1: Type: text/plain, Size: 4362 bytes --] 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.contentDocument.forms.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
next reply other threads:[~2021-03-07 13:26 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-07 13:26 Karl Dahlke [this message] 2021-03-07 16:15 ` Chris Brannon 2021-03-07 16:44 ` Karl Dahlke 2021-03-07 17:15 ` Chris Brannon 2021-03-07 18:40 ` Geoff McLane 2021-03-07 19:27 ` Karl Dahlke 2021-03-07 19:37 ` Chris Brannon 2021-03-08 8:46 ` Karl Dahlke 2021-03-08 19:31 ` Geoff McLane 2021-03-08 21:18 ` Karl Dahlke 2021-03-09 10:23 ` Kevin Carhart 2021-03-09 14:37 ` Geoff McLane 2021-03-09 22:52 ` Kevin Carhart [not found] ` <email@example.com> 2021-03-14 20:36 ` Geoff McLane 2021-03-15 9:44 ` Kevin Carhart
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [edbrowse-dev] quick js' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).