Hello,
Target release: Firefox 42
Implementation and shipping bug:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=1114554
Specification: https://notifications.spec.whatwg.org/#service-worker-api
This is a follow up to the Notification API on worker support that landed in
Firefox 41 [1].
Hello,
Target release: Firefox 41
Implementation and shipping bug:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=916893
Specification: https://notifications.spec.whatwg.org/
Gecko already implements support for the Notification API on window behind the
dom.webnotifications.enabled pref,
On Thursday, May 28, 2015 at 7:59:01 AM UTC-7, Chris Mills wrote:
> Hi all,
>
> I've finished documenting the updated Notifications API on MDN:
>
> https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API
>
> This includes the new features such as sound/vibrate that aren't supported
>
Hello,
As part of allowing various APIs (Push notifications, Notifications,
BackgroundSync etc.) to use ServiceWorkers, we need some way to start them in
the child process. I'm trying to figure out how to do this properly in e10s and
on b2g. Here is an outline, I'm hoping someone with more know
Removed pref on m-c. This will ship in 39 except for cache mode and
authentication prompt.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Thursday, January 29, 2015 at 4:57:00 PM UTC-5, nsm.n...@gmail.com wrote:
> Summary: FormData[1] has been an append only interface since it was
> introduced. The WHATWG version of the XHR spec added several methods to
> has/get/set/delete on the entries and introduced iteration support. This p
On Thursday, February 19, 2015 at 11:26:25 AM UTC-8, Benjamin Kelly wrote:
> On Wed, Feb 18, 2015 at 4:29 PM, Boris Zbarsky wrote:
>
> >
> >> 1) ESR - FF 38 is an ESR release and shipping a new API with some parts
> >> not yet supported may not be the best thing to do. What is the usual policy
> >
On Wednesday, February 18, 2015 at 9:21:28 AM UTC-8, James Graham wrote:
>
> > Support in other engines:
> > Blink: supports Fetch in ServiceWorkers since 40, and intend to enable it
> > on Window in 42 or 43 -
> > https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/fetch$20api/b
Hello,
Target release: FF 38 or 39 (feedback requested)
Currently hidden behind: dom.fetch.enabled.
Bug to enable by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1133861
The Fetch API [1] provides a simpler alternative (the fetch() function) to
XMLHttpRequest to fetch resources from the
On Friday, January 30, 2015 at 8:49:51 AM UTC-8, Chris Mills wrote:
> Hi all,
>
> We've had some web workers stuff on MDN for a while now, but it has been
> rather bitty and incomplete. I've added in the missing bits, updated stuff,
> and pulled it together underneath the following landing page:
On Thursday, January 29, 2015 at 6:41:53 PM UTC-8, Boris Zbarsky wrote:
> On 1/29/15 5:10 PM, nsm.nik...@gmail.com wrote:
> > Pref: I intend to hide this behind dom.fetch.enabled, which also controls
> > the Fetch specification.
>
> May I ask why? This seems like a totally reasonable thing to ex
On Thursday, January 29, 2015 at 6:39:22 PM UTC-8, Boris Zbarsky wrote:
> On 1/29/15 4:56 PM, nsm.nik...@gmail.com wrote:
> > The proposed patch does not add iterator support.
>
> Is there a bug tracking adding this?
https://bugzilla.mozilla.org/show_bug.cgi?id=1127703
>
> > https://xhr.spec.wh
Summary: The FormData interface allows sending forms directly via XHR. It has
previously been exposed on window. This intent is to expose it on workers and
allow the same usage, i.e:
- Creating FormData objects and adding string values or blobs to them
- Sending FormData objects via a call to xhr
Summary: FormData[1] has been an append only interface since it was introduced.
The WHATWG version of the XHR spec added several methods to has/get/set/delete
on the entries and introduced iteration support. This puts it in the same class
as URLSearchParams and Headers.
The proposed patch does
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
Hello,
For the past few months Mozilla and Google have been working on spec and
prototype implementation for ServiceWorkers [1][2]. ServiceWorkers are client
side proxies that can intercept navigation events and provide their own
responses. They are intended as a programmatic AppCache replaceme
On Tuesday, March 4, 2014 1:26:15 AM UTC-8, somb...@gmail.com wrote:
> While we have a defense-in-depth strategy (CSP and iframe sandbox should
>
> be protecting us from the worst possible scenarios) and we're hopeful
>
> that Service Workers will eventually let us provide
>
> nsIContentPolic
On Wednesday, January 29, 2014 10:35:24 AM UTC-8, Nikhil Marathe wrote:
> As off January 28, our DOM Promises implementation implements the es6
>
> promises spec. [1]
>
> It is feature complete, and passes the Promises/A+ tests. [2]
>
> I intend to enable it by default this week so that it ships
On Tuesday, November 19, 2013 10:48:24 AM UTC-8, Brandon Benvie wrote:>
> There's two mostly orthogonal concerns here. The first is the sync/async
>
> issue:
>
>
>
> console.log(1);
>
> promise.resolve().then(() => {
>
>console.log(2);
>
> });
>
> console.log(3
On Monday, November 25, 2013 12:25:00 PM UTC-8, jsan...@gmail.com wrote:
> Is there a consensus on removing Promise.jsm completely? As Benvie said, the
> majority of work will be migrating over from `sdk/core/promise.js` (sync) to
> the async Promise.jsm, which share APIs. Converting Promise.jsm
On Monday, November 18, 2013 5:36:48 PM UTC-8, Brandon Benvie wrote:
> On 11/18/2013 4:54 PM, Dave Townsend wrote:
>
> > There are add-ons using the existing promises implementations. Is there any
>
> > reason not to make those wrappers around the DOM promises to avoid
>
> > potential bustage?
>
On Monday, November 18, 2013 4:54:31 PM UTC-8, Dave Townsend wrote:
> There are add-ons using the existing promises implementations. Is there any
>
> reason not to make those wrappers around the DOM promises to avoid
>
> potential bustage?
>
>
>
> At least the add-on SDK promises library provi
On Monday, August 5, 2013 10:01:06 AM UTC-7, Mounir Lamouri wrote:
> On 26/07/13 18:29, Ehsan Akhgari wrote:
>
> > We're planning to implement a prototype of the NavigationController
>
> > interface (see bug 898524). We will try to get feedback from web
>
> > developers on the prototype and wil
23 matches
Mail list logo
