On Wed, Feb 18, 2015 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/18/15 12:06 PM, nsm.nik...@gmail.com 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
in such a situation?
On 2/19/15 2:26 PM, Benjamin Kelly wrote:
It seems to me that backporting to dom/fetch should be relatively
straightforward. Its pretty isolated code.
The real question there is how much churn you expect in that code over
the next year as the pieces that aren't one yet end up happening.
On Tuesday, February 17, 2015 at 6:33:42 PM UTC+1, Ted Mielczarek wrote:
On Tue, Feb 17, 2015, at 10:27 AM, Axel Hecht wrote:
Hi,
I'd like to write tests to validate my assumptions around what's an error
and what's a warning for localized values going into
nsTextFormatter::smprintf.
Do we realistically care about keeping this working? With perfherder
graphs, we now have a way of visualizing/tracking relative performance
(http://wrla.ch/blog/2015/02/measuring-e10s-vs-non-e10s-performance-with-perfherder/),
though I'm not sure if that's really telling us anything we don't
Right now we are running jobs on linux/windows/osx and they are all timing out.
That means we are eating up machine time for roughly an hour a job when most
jobs take 20 minutes.
By the end of the month we should either take a larger hit on our
infrastructure and get these running on
nsm.nik...@gmail.com wrote:
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
Great work!
Is there a test that verifies that fetch is correctly handled by
nsIContentPolicy
Cross-posting to dev-platform. Much of Simon's summary below applies to
Gecko.
--Jet
-- Forwarded message --
From: Simon Sapin simon.sa...@exyr.org
Date: Thu, Feb 19, 2015 at 9:28 AM
Subject: [dev-servo] CSS Houdini meeting report
To: dev-se...@lists.mozilla.org
Axel == axel-4eJtQOnFJqFBDgjK7y7TUQ
axel-4ejtqonfjqfbdgjk7y7...@public.gmane.org writes:
Axel I'm talking actual crashes, and I don't know how we would fix the
Axel text formatter. I'm glancing at
Axel
http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsTextFormatter.cpp#778,
Axel
On 18/02/15 17:31, nsm.nik...@gmail.com wrote:
We have fairly comprehensive mochitests in dom/workers/tests/fetch
and dom/tests/mochitests/fetch. The blink intent to ship email, at
the bottom, has a section which documents Canary performing well on
our tests. In addition, we pass (except
On Thu, Feb 19, 2015 at 10:25 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Fri, Feb 20, 2015 at 4:02 PM, James Long longs...@gmail.com wrote:
Personally I think what we *really* need to be working on is making
all of the DOM APIs asynchronous. That's what Servo needs anyway.
On Thursday, February 19, 2015 at 11:27:11 PM UTC+1, Tom Tromey wrote:
Axel writes:
Axel I'm talking actual crashes, and I don't know how we would fix the
Axel text formatter. I'm glancing at
Axel
http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsTextFormatter.cpp#778,
Axel and
I'm not heavily involved in platform work, so take my input as a
somewhat naïve outsider. I've been tracking this kind of stuff very
closely, especially after I got to play with react native.
The place where this is most important is mobile, and I don't think #2
is going to cut it. It's not just
Last week in Sydney I spent a lot of time talking to Chrome devs about
different approaches for 60fps effects in Web pages. There are three
different kinds of approaches being discussed (so far):
1) Apple's animation-timeline proposal, which lets CSS animations use
scroll position as an input
Sorry, I may have missed the last part of your email where you say
that you could provide touch positions as input too. This would be
neat research and I'd like to see more details.
Note however that people in the native app world believe that it's
very important that whatever applies the
On Fri, Feb 20, 2015 at 4:02 PM, James Long longs...@gmail.com wrote:
Personally I think what we *really* need to be working on is making
all of the DOM APIs asynchronous. That's what Servo needs anyway.
That's a step in the right direction for #3, and we can see much more
we can
15 matches
Mail list logo
