Le 25/02/2013 22:51, Brian Smith a écrit :
David Bruant wrote:
It seems like in theory, it could be possible to handle the content
of a cross-origin iframe in a specific Rust task (or bunch of tasks).
I thought Rust tasks were supposed to be very lightweight. If so, why not put
every iframe in a separate task, whether it is same-origin or not?
Limiting to cross-origin (and my worry for same-origin) isn't about the
weight of a task, but about determinism.
Same-origin page and iframe share the same event loop [1], so I feel it
forces content of both the main page and the iframe (I'm talking about
the code running that manipulates them, not the memory) to live in the
same task and that there is nothing to gain from task isolation. Maybe
I'm narrow-minded because I'm too used to how browsers currently work on
this point? (I would be delighted to learn so :-) )
Are there interesting parallelization opportunities given the event loop
constraint?
As a webdev, I'm particularly excited at the idea that iframes aren't a
performance annoyance and the idea to think of an cross-origin or
sandboxed (thanks to your finding below) iframe as a WebWorker+UI.
Currently, to meet the needs of webdevs, the canvas API is gaining some
ability to be transfered to web workers so that web workers work on them
and transfer the canvas back so that it'd be displayed. I find that
heavy-weight.
If I could create iframe@sandbox and draw there by sending message from
the parent in parallel of doing other things, this transferable canvas
API wouldn't be even necessary.
But if there are substantial gains to just put any iframe in an isolated
task, so be it :-)
It would be interesting to get the telemetry to see how common the following
kinds of pages are:
1. Page with no iframes
2. Page with only same-origin iframes (and how many such iframes)
3. Page with only cross-origin but same site (eTLD+1) iframes (and how many)
4. Pages with only cross-site iframes (and how many)
I agree these are interesting, but I don't understand why "only". If a
page has 7 cross-origin iframes and 2 same origin, the 7 can be put in
parallel regardless of the 2 others.
So there is something to win even if a page isn't in any of your categories.
I feel the following would be more relevant to the current concern:
* How many cross-origin iframes per page (min/max/mean/median)?
"cross-origin iframe" being only interesting as a measure of parallelism
opportunity.
# Addendum: the special same origin iframe@sandbox case
What I've described above only applies to cross-origin iframes. As it
happens, HTML5 introduced a sandbox attribute for iframes [2]. When
applied, the iframe is suddenly put in its own unique origin
(regardless of the origin inferred from its URL). So it could be
possible to consider sandboxed same-origin iframes as parallelizable.
Of course, in JavaScript, the parent of an iframe can, at any time,
remove the sandbox attribute or add the "allow-same-origin" to the
sandbox attribute (IIUC, this value gives back its origin to the
content of an iframe).
The iframe sandbox spec says "These flags only take effect when the nested browsing
context of the iframe is navigated. Removing them, or removing the entire sandbox
attribute, has no effect on an already-loaded page [in the iframe]." So, having the
isolation of an iframe depend on the value of the sandbox attribute seems like it would
work as well as having it depend on the origin of the iframe.
Oh awesome! I had missed the second (out of 3) red warning...
That makes things much simpler than I thought for the @sandbox case.
document.domain is one big reason why it may be most practical to implement
such features on a same-site (same eTLD+1)
As a nit, I came across it on the spec on that, so I'm sharing it here:
it's not exactly same eTLD+1, but rather same Public Suffix List (PSL)
suffix +1 [2].
basis instead of same-origin, if there is any reason to treat same-origin and
cross-origin iframes differently in terms of task isolation.
I'm interested in opinions on task isolation opportunities of
same-origin iframes given the shared event loop constraint, because if
it's possible, the differentiation doesn't make sense.
If not possible and assuming the document.domain trick is rare, I wonder
if the event loop merging idea would work.
David
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#groupings-of-browsing-contexts
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#dom-document-domain
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
