> the Content-Security-Policy header.

doggies, that's a mess!
Not sure if we're ever gonna deal with that.

> refuse to load frames if the domain do not match.

Well sites pull in frames from all over the internet, lots of youtube videos 
for example, and google analytics and so on.
I'm sure we need to allow frames from anywhere.

> I also think native_fetchHTTP should have some safe guards, I would just
> refuse if the incoming_url site does not match the document site but
> this might break things.

It might indeed. I wouldn't make that restriction unless (A) a spec told me to, 
and (B) other browsers do as well.

You can interact with the user from the js process; see the native prompt and 
confirm commands.
However, the number of features that only work in JS1 is growing, and will 
continue to grow.
I will probably switch so that one process is default, with $JS2=on forcing 
edbrowse into 2, and then perhaps jettisoning 2 processes altogether.
I could throw away a lot of lot of code in that event, and clean it up, and it 
would be much more readable.

Karl Dahlke
Edbrowse-dev mailing list

Reply via email to