Le 25/02/2013 21:03, Boris Zbarsky a écrit :
On 2/25/13 2:33 PM, David Bruant wrote:
2) different-origin iframe. JS from the parent can only interact with it
through message passing via postMessage.
Note that whether an iframe is same-origin or not is not
time-invariant across navigations.
Whether the same HTMLIframeElement object changes or same-origin-ness
isn't a concern I think, because what would be in a different task would
be the Window instance, not the WindowProxy.
If a given iframe is navigated, as far as the parent is concerned, the
WindowProxy remains the same (per spec anyway) and the underlying Window
is in the same task in the case of same-origin and a dummy stub in the
different-origin case.
In a way, navigation just means "throw away the Window and plug a new
one to the WindowProxy".
Andreas Gal wrote:
Its also not time-invariant when document.domain is used, correct?
True. I guess the cases of "iframe initially has a different origin than
its parent, but JS can change that" are more numerous than I originally
thought.
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). The few
allowed communications (postMessage, iframe size in the parent, etc.)
would "just" be handled by cross-task communication.
Yes, as long as you handled navigations possibly moving the iframe to
a new task.
As suggested above, the HTMLIframeElement and the WindowProxy would stay
in the parent content task, so no need to move them.
In cases where 2 given documents are time-independently of different
origins, the iframe content would be created in a new task. If
navigation happens, the only thing that changes in the parent is where
communication from the parent is directed to. Maybe it's a new different
task (other cross-origin document), maybe it's in the same task (same
origin document).
For the cases of script-dependent cross-origin-ness (document.domain,
@sandbox="allow-same-origin"), I wonder if it's possible to start in a
new task (optimistically, hoping cross-origin-ness won't change) and
move back the runtime (merging event loops I guess?) to the parent task
when the parent and the iframe end up having the same effective script
origin.
I assume there is no need to move most data because if the parent
content and the iframe content may run in 2 different tasks, they remain
in the same process (so share memory). Only the parallelism needs to be
taken down.
Does it sound doable? reasonable?
* when the iframe@src changes, all the memory that's specific to the
task can be released directly without waiting for GC graph traversals or
refcounting
That may or may not be true depending on how session history works.
In the sense that browsing back may need the data to display the page
more quickly? Or were you thinking of something different?
Thanks for the feedback,
David
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
