If we did b, I believe it would also help ship visibilitychange events on iframes when they are detached. This is currently the blocking api change to killing unload events. +Kinuko fyi.
So, I defer to others on whether b is possible, but we'd get some extra value from it aside from stability.
--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jw2U9W_G%3Daq759eadQaxT253cx-hah0aS3FQedOE91ZpA%40mail.gmail.com.
The last I checked, Edge and Firefox don't allow closures created by a detached iframe to run (they throw an exception): only Blink and WebKit support this.
Using this for visibilitychange events is interesting, but there are some things that would be confusing: for example, what does window.document work if the frame's been navigated? Do we end up directly exposing the global object to JS once the context is detached instead of the global proxy?
Daniel
Do we end up directly exposing the global object to JS once the context is detached instead of the global proxy?
Firefox has proxies between the contexts as I understand it. We can't really do that, nor do I think we should build the infrastructure for it. Could we instead disable the various platform apis and navigate the document to a unique origin or something of that nature?
In general we probably need to get together with the various browsers and the spec authors and come up with something that's not possible and matches some reality. I don't think anyone follows the spec fiction today.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAF3XrKpHKQM%3DZdNVwr%3DWuu3EgEwk%3DjiMJVce6cC7DGK2haT8Qg%40mail.gmail.com.
Firefox has proxies between the contexts as I understand it. We can't really do that, nor do I think we should build the infrastructure for it.
Could we instead disable the various platform apis and navigate the document to a unique origin or something of that nature?
On Jun 22, 2016 3:50 PM, "Yuki Shiino" <yukis...@chromium.org> wrote:
>>
>> Firefox has proxies between the contexts as I understand it. We can't really do that, nor do I think we should build the infrastructure for it.
>
>
> V8 supports the global proxy object and global object (and hidden prototype between them), and we're using that proxy system. The global proxy object corresponds to WindowProxy and the global object corresponds to Window. So we're following the spec's model so far, I think.
>
> Also, we're sometimes writing frame()->domWindow() in Blink's codebase, and this is what WindowProxy requires. In this case, frame() corresponds to WindowProxy and frame()->domWindow() corresponds to Window. IIUC, this is the reason why we need to write obj->frame()->domWindow() instead of obj->domWindow().
Yup, Firefox has a membrane between the two contexts for all objects though, not just the window. It lets them do some fancier things. We don't have anything like that.
>
>
>> Could we instead disable the various platform apis and navigate the document to a unique origin or something of that nature?
>
>
> I don't understand how this helps.
>
> iframe = document.createElement('iframe');
> document.body.appendChild(iframe); // Attach the iframe.
> w = iframe.contentWindow; // Save the WindowProxy object of the iframe's browsing context.
> d = iframe.contentDocument; // Save the Document of |w|.
> F = w.Function; // Save Function, too.
>
> iframe.remove(); // Detach the iframe.
>
> iframe.contentWindow; // Returns null, but it does NOT mean |w| is null.
> w; // |w| is the same non-null WindowProxy object even if it pointed to another Window.
> d; // |d| is also a non-null Document.
> F; // You can use F, too, and run any scripts in that context.
>
> Even if we create a new Window with a new Document with a unique origin and make |w| point to that new Window, you can still access to |w|, |d|, and |F| above. As long as |F| is alive, the context must exists, and you can run any code in the creation context of |F|.
>
> This is the reason why haraken@ wrote in his first mail of this thread that it's hard to forbid all the script execution. If we're going to forbid user scripts to access to DOM objects on detached frames, we have to check if the context is detached or not for all the DOM attributes and DOM operations, because user scripts can save any DOM objects for later use.
> // |d| is the saved Document above.
> d.attribute // Needs to check if |d|'s context is detached or not
> d.operation() // Needs to check if |d|'s context is detached or not
That doesn't really make sense. You need a proxy at all JS functions, it doesn't make sense that appendChild would throw but Array forEach wouldn't.
>
> As long as user scripts can save arbitrary objects (including DOM objects) for later use before detaching, I don't have a good idea to forbid user scripts to access to the DOM objects on detached frames.
>
We don't need to forbid all script access, nor should we. The issue is around security origins of the content and apis generated from the frames. Oilpan solves much of the strange lifetime problems, the rest can be solved by disabling the api layer below the web platform features (ex. Fetching) and by forcing the document to take on a unique origin so the frame looses access to any resources across the frame tree.
In either case blink and WebKit already disagree on various things here since we've diverged the code so much. Firefox also had different behavior from edge. I'm pretty sure the spec disagrees with everyone. We need to figure out what's possible in everyone's engine and spec that.
- E
The issue is around security origins of the content and apis generated from the frames.
The issue is around security origins of the content and apis generated from the frames.I don't understand this point and what you mean. If the iframe is a cross-origin, you cannot access to any object other than Window and Location regardless of whether it's detached or not. "detached or not" has nothing to do with the origins. While we're talking about how to treat detached frames, why origins matter?
--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAO9Q3i%2B1i5JNxuZX_GsDw1hzmYrvqaGgrE7pb_N6_0z%3DKK3ePg%40mail.gmail.com.
Now you can do contentWindow.setTimeout(), contentWindow.fetch(), new contentWindow.AudioContext(), and much more. The question is what should all of that do? What's the security context of the iframe now that it's no longer inside the frame tree?
I'm interested in supporting detached frames as a system of binding's layer, and I'm okay that specific APIs do not support specific things in case of detached frames. I think it's better to separate what specific APIs support from what binding layer supports as a binding system.
+creis
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAO9Q3i%2B1i5JNxuZX_GsDw1hzmYrvqaGgrE7pb_N6_0z%3DKK3ePg%40mail.gmail.com.
+creis
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAO9Q3i%2B1i5JNxuZX_GsDw1hzmYrvqaGgrE7pb_N6_0z%3DKK3ePg%40mail.gmail.com.
--Kentaro Hara, Tokyo, Japan
--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAN0uC_SK1Eo8CnwHDZBroKGvyU7udFfr14ufQTtKivHNEfgN2Q%40mail.gmail.com.