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 Fri, Jul 24, 2015 at 3:41 AM, Boris Zbarsky bzbar...@mit.edu 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
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 theory
On Thu, Jul 23, 2015 at 6:32 AM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
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 bzbar...@mit.edu 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
On Tue, Jul 21, 2015 at 5:01 PM, Honza Bambas hbam...@mozilla.com 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
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
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
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
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.
11 matches
Mail list logo
