On Fri, Jul 24, 2015 at 3:41 AM, Boris Zbarsky wrote:
> On 7/23/15 11:36 AM, Anne van Kesteren wrote:
>
>> By "SVG resource document" do you mean one that is fetched as an
>> image?
>>
>
> In Gecko's case I specifically mean one fetched as a paint server.
>
> It's somewhat of an implementation de
On 7/23/15 11:36 AM, Anne van Kesteren wrote:
By "SVG resource document" do you mean one that is fetched as an
image?
In Gecko's case I specifically mean one fetched as a paint server.
It's somewhat of an implementation detail, possibly; the reason we do it
is that we had a bunch of code that
On Thu, Jul 23, 2015 at 8:19 AM, Boris Zbarsky wrote:
> On 7/23/15 9:47 AM, Anne van Kesteren wrote:
>> Load groups roughly matches the "fetch registry" I think. I should
>> probably rename that "fetch group" as Ben suggested to me privately.
>> Filed https://github.com/whatwg/fetch/issues/92 to d
On 7/23/15 9:47 AM, Anne van Kesteren wrote:
Load groups roughly matches the "fetch registry" I think. I should
probably rename that "fetch group" as Ben suggested to me privately.
Filed https://github.com/whatwg/fetch/issues/92 to do so.
Sort of. Except fetch group is per-global but there are
On 23/07/15 15:47, Anne van Kesteren wrote:
> > * Construct an nsIURI. Might need to take things such as the
> document base
> > URI and charset into account.
>
> For many APIs these days you need to parse the URL before you hand it
> off. That seems like a somewhat saner setup too, though in theo
On Thu, Jul 23, 2015 at 6:32 AM, Ehsan Akhgari wrote:
> I think this is a good idea in general, but I'm not sure how well the high
> level fetch API would map to something internal.
1) fetch() is not exactly high-level.
2) We're not talking about fetch(), but about the fetch algorithm,
which is
On 2015-07-17 2:16 PM, Benjamin Kelly wrote:
I thought a little bit more about this after stepping away from my computer.
I think some of our implementation issues for service workers currently
stems from the fact that the fetch spec and necko have modeled the problem
with different primitives:
On Tue, Jul 21, 2015 at 5:01 PM, Honza Bambas wrote:
> The main offenders here are:
> - synchronous "on-*-request" global notifications
>
I believe this is mostly what :sicking refers to when he talks about
[1] https://etherpad.mozilla.org/BetterNeckoSecurityHooks
and I agree that would be usef
On 7/18/2015 1:42, Kyle Huey wrote:
To be abundantly clear, no I/O should be happening (or is, to my knowledge)
on the main thread when you use XHR. The limitation today is that various
Necko state operations (e.g. opening a channel) can only happen on the main
thread.
The main offenders here a
On 18/07/15 01:42, Kyle Huey wrote:
> To be abundantly clear, no I/O should be happening (or is, to my
> knowledge) on the main thread when you use XHR. The limitation today is
> that various Necko state operations (e.g. opening a channel) can only
> happen on the main thread. But that doesn't mean
To be abundantly clear, no I/O should be happening (or is, to my knowledge)
on the main thread when you use XHR. The limitation today is that various
Necko state operations (e.g. opening a channel) can only happen on the main
thread. But that doesn't mean that we are doing I/O there.
- Kyle
On Jul
On Fri, Jul 17, 2015 at 1:43 PM, David Rajchenbach-Teller
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 mai
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
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 f
I thought a little bit more about this after stepping away from my computer.
I think some of our implementation issues for service workers currently
stems from the fact that the fetch spec and necko have modeled the problem
with different primitives:
- necko provides an object (nsIChannel) to r
On Fri, Jul 17, 2015 at 5:26 PM, Benjamin Kelly wrote:
> Do you have specific ideas about how you think things should be refactored?
Not really. I believe one of the things that came up was that Necko's
interface was not quite ideal and that most of this really ought to be
in Necko instead, but I
On Fri, Jul 17, 2015 at 11:20 AM, Anne van Kesteren
wrote:
> In Whistler we discussed security concerns around service workers and
> a lot of them stem from the fact that we don't have a good interface
> in Gecko for Fetch[1]. Something that handles requests for all web
> platform features we hav
In Whistler we discussed security concerns around service workers and
a lot of them stem from the fact that we don't have a good interface
in Gecko for Fetch[1]. Something that handles requests for all web
platform features we have and deals with CSP, HSTS, Referrer Policy,
redirects, service worke
Hello,
Summary: The Fetch specification unifies fetching across the web platform. The
intention of Bug 1039846 is to implement the content facing aspects of the
Fetch specification, namely:
- Request/Response/Headers/FetchBodyStream objects
- Expose the fetch() method on windows and workers.
fe
19 matches
Mail list logo
