Re: [edbrowse-dev] interwindow bleed

[Adam Thompson <arthompson1990@gmail.com>]

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.