Re: [whatwg/fetch] Aborting a fetch: The Next Generation (#447)

@Morantron
A version using Blob API has been added. It will work without `'unsafe-inline'` but it is much slower (still faster than WebWorker). [exec-blob.js](https://github.com/optimalisatie/exec.js/blob/master/exec-blob.js)

@jakearchibald 
We are investigating it. It appears to be possible but the current version of exec.js (optimized for speed) may not be the correct way to achieve multi-threading.

> Chromium keeps track of the full frame tree for each tab in the browser process.  WebContents hosts a tree of FrameTreeNode objects, mirroring the frame tree of the current page.  Each FrameTreeNode contains frame-specific information (e.g., the frame's name, origin, etc).  Its RenderFrameHostManager is responsible for **cross-process navigations in the frame**, and it supports replicating state and routing messages from proxies in other processes to the active frame.
> 
> Frame-specific logic in the content module's RenderView and RenderViewHost classes has moved into routable RenderFrame and RenderFrameHost classes.  We have one full RenderFrame (in some process) for every frame in a page, and we have a corresponding but slimmed down RenderFrameProxy as a placeholder in the **other processes that can reference it** (the iframe).

https://www.chromium.org/developers/design-documents/oop-iframes

I found the following Chromium dev topic from 2015 in which they are experimenting with OOPIF + contentWindow access.

https://groups.google.com/a/chromium.org/forum/#!topic/blink-reviews/Ur1IJxLzQao

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/447#issuecomment-316356386