On Thu, Feb 19, 2015 at 10:25 PM, Robert O'Callahan
wrote:
> On Fri, Feb 20, 2015 at 4:02 PM, James Long 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 dire
On Fri, Feb 20, 2015 at 4:02 PM, James Long 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 get out of the main
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 animatio
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 s
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 inste
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#
> "Axel" == axel-4eJtQOnFJqFBDgjK7y7TUQ
> 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 had no idea how to fix
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.
If
On Wed, Feb 18, 2015 at 4:29 PM, Boris Zbarsky 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?
>>
>
> How h
Cross-posting to dev-platform. Much of Simon's summary below applies to
Gecko.
--Jet
-- Forwarded message --
From: Simon Sapin
Date: Thu, Feb 19, 2015 at 9:28 AM
Subject: [dev-servo] CSS Houdini meeting report
To: "dev-se...@lists.mozilla.org"
Last week I was in Sydney for the
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 (for extensions l
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 f
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::sm
> 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 integr
15 matches
Mail list logo