On Sat, Nov 21, 2015 at 9:42 AM, Ben Kelly wrote:
> I think the best thing we can do right now is get a second implementation
> into wide circulation. This will highlight compat issues yes, but also
> help avoid baking chrome specific behavior into all the sites using service
> workers.
>
Yes.
On 11/20/15 3:42 PM, Ben Kelly wrote:
No. I think what we have works on the sites/demos/wpt tests available
today. We feel its compatible enough to ship. We'll fix further compat
issues using our standard train model.
OK.
I think the best thing we can do right now is get a second implement
On 11/20/15 3:26 PM, Ben Kelly wrote:
I guess I should mention the biggest change in the spec that has not been
implemented by either chrome or firefox.
The spec now exposes the Response.url passed to the
FetchEvent.respondWith() to the outer network request. So base URLs for
stylesheets and wo
On Fri, Nov 20, 2015 at 3:30 PM, Boris Zbarsky wrote:
>
> Another compat issue we need to fix is returning the same
>> ServiceWorkerRegistration object repeatedly from certain APIs. This was
>> something that changed a few times in both the spec and chrome.
>>
>> Fixing these minor compat issues
On 11/20/15 3:21 PM, Ben Kelly wrote:
The spec is converging to a stable v1, but things are still changing. The
core functionality has been stable for a while, though.
OK. I guess my question is whether, for example, waiting for another
release cycle would significantly improve things here o
On Fri, Nov 20, 2015 at 3:21 PM, Ben Kelly wrote:
>
> On Fri, Nov 20, 2015 at 3:01 PM, Boris Zbarsky wrote:
>
>>
>> 1) How confident are we that the spec is stable/correct?
>>
>
> The spec is converging to a stable v1, but things are still changing. The
> core functionality has been stable for
On Fri, Nov 20, 2015 at 3:01 PM, Boris Zbarsky wrote:
>
> 1) How confident are we that the spec is stable/correct?
>
The spec is converging to a stable v1, but things are still changing. The
core functionality has been stable for a while, though.
> 2) How confident are we that our implement
On 11/20/15 1:34 PM, Ben Kelly wrote:
Please let me know if you have any questions are concerns.
I actually have a few questions.
1) How confident are we that the spec is stable/correct?
2) How confident are we that our implementation, Chrome's, and the spec
all match? I know we were work
Also, webconsole logging for Service Workers is preffed behind
devtools.webconsole.filter.serviceworkers, which will be enabled by default in
https://bugzilla.mozilla.org/show_bug.cgi?id=1201962.
Brian
> On Nov 20, 2015, at 10:34 AM, Ben Kelly wrote:
>
> In Firefox 44 we intend to enable Serv
In Firefox 44 we intend to enable Service Workers and FetchEvents by
default on desktop and android. These features will not be enabled on
Firefox OS yet.
They has been developed behind the following preferences:
dom.serviceWorkers.enabled
dom.serviceWorkers.interception.enabled
dom.servic
On 11/20/15 5:09 AM, Neil wrote:
Chris Peterson wrote:
mozilla-build tools already use 1.3
When did it get upgraded? (My mozilla-build only has yasm 1.1)
Last year according to bug 1113450:
https://bugzilla.mozilla.org/show_bug.cgi?id=1113450
__
FYI: Trees will be closed during our normal Tree Closing Window. However,
some of the work mentioned below has been deferred, so trees should be
reopened by 11:30 PT.
-- Forwarded message --
From:
Date: Mon, Nov 16, 2015 at 8:54 AM
Subject: [Planned] TCW 2015-11-21 0600-1630 PST 2
<3<3<3
On 11/19/2015 3:23 PM, Chris AtLee wrote:
Over the past months we've been working on migrating our Windows builds
from the legacy hardware machines into Amazon.
I'm very happy to announce that we've wrapped up the initial work here, and
all our Windows builds on Try are now happening in
On 18/11/15 19:26, phow...@ccvschools.com wrote:
> This is definitely an important feature, but I'm not holding my
> breath. I have had a lot of experience with Mozilla over the years
> and I really doubt anything will materialize in the near future.
Feeling particularly entitled today, are we?
Chris Peterson wrote:
mozilla-build tools already use 1.3
When did it get upgraded? (My mozilla-build only has yasm 1.1)
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/l
On Fri, Nov 20, 2015 at 12:23 PM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:
> It could be improved a bit, but the real issue is that JavaScript is a
> high-level, garbage-collected, dynamic programming language, while C is
> a low-level, memory-unsafe, type-unsafe, statically compiled
It could be improved a bit, but the real issue is that JavaScript is a
high-level, garbage-collected, dynamic programming language, while C is
a low-level, memory-unsafe, type-unsafe, statically compiled programming
language.
I have heard a few ideas floating around on how this could be improved,
On 18/11/2015 16:04, David Rajchenbach-Teller wrote:
> Well, the main problem is that js-ctypes is very hard to use, even
> harder to use without causing memory leaks or crashing the process.
> Think the worst parts of both C and JavaScript together.
Are these problems inherent in ctypes or is it
Ting-Yu Lin:
> Summary: The is used as a disclosure widget from which the user
> can
> obtain additional information or controls. is used as a summary or
> legend of the details. To expand the details, the user could click on the
> summary or by adding a bool attribute 'open' to the details.
>
>
On Fri, Nov 20, 2015 at 3:16 AM, Jet Villegas wrote:
> I expect we'll see more usage once all the browsers have
> it: http://caniuse.com/#feat=details
Agreed, I think the same is true for et al. Styling
is an important consideration and we should solve it if we can. But
the bare basics for a fe
On Fri, Nov 20, 2015 at 9:49 AM, Jonas Sicking wrote:
> I'd be quite happy if someone else would :)
Filed https://github.com/w3c/hr-time/issues/22 on the general nested
worker problem. Filed https://github.com/w3c/hr-time/issues/23 on the
Client object thing.
--
https://annevankesteren.nl/
___
On Thu, Nov 19, 2015 at 5:38 PM, Boris Zbarsky wrote:
>> Though Service Workers do actually have a 'client' object which
>> represent window objects. So we could enable passing those as global
>> to the translate function.
>
> That's a good idea. Want to raise it with the webperf WG? Seems like
Great job!
Il 19/11/2015 21:23, Chris AtLee ha scritto:
Over the past months we've been working on migrating our Windows builds
from the legacy hardware machines into Amazon.
I'm very happy to announce that we've wrapped up the initial work here, and
all our Windows builds on Try are now happen
23 matches
Mail list logo
