Le 10/03/2015 23:48, Jonas Sicking a écrit :
Even more importantly, if http://site-a.com opens an <iframe> to
http://site-b.com/widget.html, it's expected that the iframe is loaded
using site-b's cookies. While we theoretically could use a different
child process to load the <iframe>, Gecko isn't able to do this yet.
What I'm hoping we can do eventually, is just that though. I.e. make
each origin load in a separate process. Even if the origin is loaded
inside an <iframe> inside another origin.
Note that this is tedious as two contexts with originally different
origins may end up with the same origin if they set document.domain on
both sides.
However, this question is taken care of for @sandbox-ed iframes on the
standards side as well as in Firefox and Chrome. (See
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23040 )
That way we could use process boundaries to ensure that a given origin
is not able to read data that belongs to another origin.
Hopefully this is something that the platform team will start looking
at once the initial process separation work is done for desktop.
I am looking forward to this moment.
And I believe this relates to the question at hand about vendor-specific
APIs. Mozilla has expressed the intention to implement new API to have
<canvas> handled in a Worker (and I haven't read interest for that from
other browsers, please correct me if I'm mistaken). However, it appears
that process-isolated iframes should lead to the same performance
benefits without needing any new API (but perhaps strongly encouraging
other vendors to improve their iframe@sandbox implementation).
David
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
