On Fri, Jul 17, 2015 at 1:43 PM, David Rajchenbach-Teller <dtel...@mozilla.com> wrote: > Would any such reimplementation have an effect on the ability to execute > XHR/Fetch I/O off the main thread? I haven't checked if this has any > consequence in practice, but the idea that all my XHR calls are executed > on the main thread is one of the many things in the architecture of > Firefox that don't help me sleep well at night.
Yes. One of the goals of the changes in that etherpad is to enable doing network stuff off the main thread. No one is working on that part though, and it's not on anyones backlog. If you're interested, let me know and I'd be happy to point you to the parts that's needed to archive that specifically. / Jonas > Cheers, > David > > > On 17/07/15 22:24, Jonas Sicking wrote: >> I don't think the problem here is coming up with an architecture, but >> rather having time to implement it. I think many of the specs you >> mention would be a lot easier if we implemented the "Hooks for >> security policies" proposal from [1]. >> >> There's already work going on for implementing the "New API for >> creating channels", "Security Flags" and "Opening channels" sections >> of [1]. This should be enough to enable channels to know if they have >> a "tainted" response or not. But we would also need to rearchitecture >> all relevant callsites to actually look at that. I would imagine some >> already do, but not all of them. >> >> Referrer policies would require other solutions entirely. >> >> Anyhow, the short of it is that the missing piece here is having the >> time to make these changes. >> >> [1] https://etherpad.mozilla.org/BetterNeckoSecurityHooks > > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
